1. Си / Говнокод #27103

    +1

    1. 1
    #define LEAP_YEAR_OR_NOT(year)( ( year % 4 ) ? ( 0 ) : ( 1 ) )

    Тот кто это писал, видимо рассуждал примерно так:

    - В 2100 году это конечно забагует, но это будет уже не моя проблема.

    Запостил: j123123, 11 Ноября 2020

    Комментарии (36) RSS

    • Хотя вот если существует реинкарнация, его этот баг может задеть в следующей жизни. Или если крионика, омоложение какое-то. Тут надо хорошо подумать.

      (да, код писался после 2000-го)
      Ответить
      • Кстати это довольно любопытный способ поднасрать без последствий. Сделать незаметный баг в хуйне с датами, который сработает через 300 лет как бомба с часовым механизмом, археологи будущего возможно даже найдут автора этого бага, но смогут разве что нассать ему на могилу (но ему уже будет пофиг).
        Ответить
        • Ну это надо сделать что-то прям настолько охуенное, что оно через 300 лет ещё кому-то нужно будет...
          Ответить
          • Например прошивку для очередного космического аппарата.
            Ответить
            • Она будет на джаваскрипте чтобы космонавты ее могли сами поправить.

              З.Ы. У crew dragon'ов гуйня на джаваскрипте.
              Ответить
              • Кто подправит прошивку вояджера?
                Ответить
                • Примерно через 296 тысяч лет «Вояджер-2» разойдётся с Сириусом на расстоянии 4,3 светового года.

                  И никаких переполнений, заметьте. Вот раньше умели делать, а?
                  Ответить
                  • Ему будет пофиг на переполнения, ритеги и так уже почти сдохли.
                    Ответить
              • undefined тысяч километров до цели. Желаете [object Object]?
                Ответить
              • > З.Ы. У crew dragon'ов гуйня на джаваскрипте.

                А "бэкенд" на PHP?
                Ответить
    • так а 1800, 1900 итд? тоже не сработает же?
      Ответить
      • Ну а оно и не нужно. Когда там дата слетает, оно выставляет 01.01.2000 (кстати это баг, надо 2001 выставлять)
        Прошлого не существует.
        Ответить
        • Это ещё ладно. Я видел телефон на котором будущего не существовало. Походу тупо вбили календарь до 2015, подумав что всё равно столько юзать не будут.
          Ответить
        • > (кстати это баг, надо 2001 выставлять)

          Хотя нет, 2000 ведь на 400 делится. Так что если считать с этого момента этот код забагует в прошлом первый раз в 1900 и в будущем в 2100. До 2100 эту хрень вряд ли кто будет использовать, так что всё нормально. Археологи разве что откопают на помойке и обнаружат баг.
          Ответить
    • Ну да, тем более если там 32-битная дата, которая и так в 2038 переполнится.
      Ответить
      • неоспоримое преимущество макросни перед инлайнерством состоит в том, что оно работает любыми типами:)
        Ответить
        • Именно поэтому я за «шаблоны».
          Ответить
          • да, типа
            template<typename T>
            inline bool is_leap(T year) {
               return (year % 4);
            }
            Ответить
            • % на плавучих питухах не работает
              Ответить
              • % много где не работает, тут ведь не сказано, какой тип
                нужен std::is_integral?

                хотя ведб и так кормпиляция упадет, но лучше так
                #include <type_traits>
                template<typename T>
                inline bool is_leap(T year) {
                    static_assert(std::is_integral<T>::value, "petuh");
                    return (year % 4);
                }
                Ответить
            • "4" - какая-то анскильная питушня. Оно же не будет работать как Num a => a, или конпелятор догадается?
              Ответить
      • Да, такой проверки вполне хватит для unix времени на всём допустимом диапазоне.

        Минимальная дата в знаковом 32-битном представлении — 13 декабря 1901 года, 20:45:52 UTC (0x80000000, −2 147 483 648 секунд от 1 января 1970 года).

        А 2038 это сильно меньше чем 2100
        Ответить
    • В 2038-м году забагуют программы, хранящие дату в int32_t.

      Ещё через 68 лет (т. е. в 2106-м году) забагуют программы, хранящие дату в uint32_t.

      Код написан с расчётом, что всё равно надо будет переписывать.
      Ответить
      • Поэтому надо в bigint хранить, чтоб уж наверняка. Хотя тогда слишком большая дата может всю память занять.
        Какое несовершенство мира )))
        Ответить
      • Кто-то отмечал 1600000000 timestamp, кстате?
        Ответить
    • К слову, а вдруг там за 100 лет в землю ёбнет астероид, орбитальные параметры изменятся и придётся вычислять високосность по-другому?
      Ответить
      • А про то, что эту функцию можно вызывать не для текущего года, никто не подумал?
        Ответить
        • Ну там j314159 выше пишет, что это просто бортовое время какого-то девайса. Так что совсем левые даты туда никто писать не будет. А с 1900 по 2100 этот код вполне рабочий.
          Ответить

    Добавить комментарий