1. C++ / Говнокод #20355

    +4

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    enum SomeEnum
    {
        // ...
        SomeShit = 0xD6,
        // ...
    };
    
    // ....
    
        Byte opcode = ReadSomeShit<Byte>();  // функция читающая raw memory в нужном представлении
        // из raw memory считано значение эквивалентное 0xD6
        // ...
        if (opcode == SomeShit) // условие не выполнилось
        {
            // do stuff
        }
    
    // ...

    почему? а потому что кто додумался до
    typedef char Byte;
    который (хоть и не обязан быть, но) знаковый

    и даже сраного ворнинга не выдало
    причина правда обнаружилась достаточно быстро, ибо в дебагере в opcode красовалось -42 а в SomeShit 214

    https://ideone.com/02TpT7 на первый взгляд вызывает когнитивный диссонанс
    обожаю кресты

    Запостил: meinf, 08 Июля 2016

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

    • Это сишное говнонаследие.
      Ответить
      • ну в целом да, но я потом сходил проверил на шланге, и он все таки выдает ворнинг про сравнение, а вот студия и гцц не хотят ни в какую
        Ответить
    • > typedef char Byte;
      Выстрел в левую ногу
      > enum SomeEnum
      Выстрел в правую ногу.

      Да, кресты это позволяют, и не говорите, что мы вас не предупреждали.

      BTW, в C++11
      enum SomeEnum : int8_t

      - сделает вам ошибку компиляции: https://ideone.com/sOaUou
      Ответить
      • > Выстрел в левую ногу
        > Выстрел в правую ногу.

        да это понятно, но человек писавший это не знал/не предусмотрел, компилятор не подсказал, а язык разрешает...и потом внезапно находится бага с непонятно откуда растущими ногами

        > enum SomeEnum : int8_t

        про это я тоже вкурсе, так и сделал кстати в конечном счете (только от того самого Byte, который стал uint8_t)
        Ответить
    • Вот тебе ещё стрела в колено: https://ideone.com/106IOF
      Ответить
      • ну тут классика signed/unsigned, это, по-моему, ловится любым компилятором
        Ответить
      • Это хотя бы жестко задокументировано в стандарте и компиляторы исправно ругаются
        Ответить
        • А знаковое расширение char -> int тоже задокументировано и вполне интуитивно... Странно было бы взять (char)(-42), отнять от него (int)214 и получить ноль вместо (int)(-256).
          Ответить
          • уточни. Расширение signed char -> int или char -> int? Знаковость char id же
            Ответить
            • signed char (на данном компиляторе при данной фазе луны он же был signed).
              Ответить
    • Когда я пишу на крестах - у меня возникает стойкое ощущение, что я иду через минные поля.
      Ответить
      • Но многие отчаянные искатели приключений при этом ещё и отключают миноискатель.
        Ответить
      • З.Ы. А разве в жабе не то же самое получится? Попробовал - абсолютно то же самое. Знаковые числа такие знаковые.
        Ответить
      • а ты не складывай себе под ноги мины
        Ответить
    • никогда из С++ не стрелялся чтоли?
      Ответить
    • Будь по другому, int(int8_t(-42)) выдавал бы 214, несмотря на отсутствие преобразования в беззнаковое.

      Меня по факту забавляет что тип char не является ни unsigned char, ни signed char
      Ответить

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