caxapa.ru :: enum уже определил FALSE и TRUE, повторно их определять не нужно. Они просто "чудом" совпали, поэтому ошибки нет. Хотя последние версии IAR предупреждают о переопределении. Warning [Pe188] на какую строку? Он предупреждает о том, что переменной типа bool_TypeDef присваивается значение не принадлежащее enum, я такой строки не вижу.

VLLV (21.09.2020 00:32 - 00:36, просмотров: 431) ответил teap0t на #11 Объясните, пожалуйста, почему такое объявление работает (нет ошибок и предупреждений)

enum уже определил FALSE и TRUE, повторно их определять не нужно. Они просто "чудом" совпали, поэтому ошибки нет. Хотя последние версии IAR предупреждают о переопределении. Warning [Pe188] на какую строку? Он предупреждает о том, что переменной типа bool_TypeDef присваивается значение не принадлежащее enum, я такой строки не вижу.

Ответить

- В месте использования teap0t(87 знак., 21.09.2020 00:36)
  - Интересно. Уберите два #define, будет предупреждение? - VLLV(21.09.2020 00:38)
    - Исчезли. Так даже лучше, потому что в той же MISRE не рекомендуется инициализация енумов. Т.е. сейчас нет предупреждений, а код выглядит так teap0t(52 знак., 21.09.2020 00:58)
      - Потому что enum сам их "инициализирует", а точнее определяет. Правда, у многих устоялось присвоение первого элемента равным нулю, например вот так: VLLV(150 знак., 21.09.2020 00:58)
        
        ОК. - teap0t(21.09.2020 01:03)
- эт где true false определены через enum ?? - Aleksey_75(21.09.2020 00:35)
  - у автора. Он видимо решил попробовать такой вариант. - VLLV(21.09.2020 00:37)
    - Да. Я попытался уйти от bool, на который ругается компайлер при включённой опции "MISRA 2004". Найти не могу. Что-то похожее на "Error[Pm011]: the basic types of char, int, short, long, float, and double should not be used, but specific-length equivalents should be typedef'd for the specific compiler, and these type names used in the code (MISRA C 2004 rule 6.3)". Я попробовал собрать свой тип с двумя состояниями по обнаруженному в исходниках образцу. А чего не teap0t(7 знак., 21.09.2020 00:51 - 01:19)
      - MISRA C RUS RxTx(21.09.2020 02:18, ссылка)
        
        А offsetof чем не угодил? (правило 120). - Ale3000(21.09.2020 09:05)
        
        В оригинальном документе иная нумерация пунктов. Нафиг. - teap0t(21.09.2020 08:19)
      - все так, но как во всем, есть плюсы и минусы : + : более строгая типизация, -: переменная созданного типа будет иметь размер int и абсолютной типизации все равно не достичь из-за невозможности присвоить этот тип битовым полям. - VLLV(21.09.2020 01:03)
      - с MISRAой у вас будет много интересных загогулин! ))) - Aleksey_75(21.09.2020 00:57)
        
        Нужны красивые тэги в резюме. Я прочитал документ по MISRA от IAR. Там, вроде, всё разумно, многие правила я и так соблюдал. - teap0t(21.09.2020 01:00)
        
        Мое любимое правило 60 , от него всех знакомых "чистых" программеров люто штырит.Много лет над ними издеваюсь. - PlainUser(21.09.2020 06:55)
        
        Это про обязательный пункт else? По-моему это вполне корректное требование, убирающее неоднозначность. Одобряю. - teap0t(21.09.2020 08:20)
        
        Ну да, если тэг про MISRA важнее, чем тэг "я это сделаль", то путь верный :) - VLLV(21.09.2020 01:05)
        
        Не понял. Поясните. - teap0t(21.09.2020 01:10)
        
        Потому что MISRA накладывает существенные ограничения на "высоуровневость" языка, вынуждая использовать С как обычный ассемблер. Поэтому многие удобные возможности урезаны, например X-macro из-за невозможности использовать #undef. И многие другие. Поэтому реальный проект программиста со средним опытом требованиям MISRA не соответствует. - VLLV(21.09.2020 01:20)
        
        ))) я с плюсами совсем не дружу но есть MISRA C++ уж не знаю что там ибо мне закидонов на MISRA С хватило за глаза ))) - Aleksey_75(21.09.2020 01:25)
    - )) ужоснах int32 отдать под булевы значения - Aleksey_75(21.09.2020 00:41)
      - Я пока просто палкой в это всё тычу и смотрю, что происходит. Как перестаю понимать - задаю вопрос. - teap0t(21.09.2020 00:56)
        
        если есть встроенный тип bool забейте и оставьте как есть Aleksey_75(106 знак., 21.09.2020 00:59)
        
        Говнокод детектед. Как минимум надо #define true (!false). Ну и делать вид, что самопальный bool работает так же, как настоящий -- это обман, он работает иначе. То есть раскидывание граблей. Надо как минимум назвать это всё по-другому. - SciFi(21.09.2020 09:05)
        
        Я свой обозвал иначе, т.е. этой ловушки избежал, но в чём инаковость работы? - teap0t(21.09.2020 09:08)
        
        Вот: SciFi(267 знак., 21.09.2020 09:12)
        
        Спасибо. Согласен с VLLV. И, кстати, периферийная библиотека ST всегда ведёт сравнение в форме teap0t(312 знак., 21.09.2020 09:53)
        
        Что значит "всегда"? Вы всё проверили? Такие штуки имеют тенденцию обнаруживаться в самый неподходящий момент. В поле, например. - SciFi(21.09.2020 09:55)
        
        Ну, ладно к словам-то цепляться. Я о принципе. За весь код говорить не буду, но подход виден. - teap0t(21.09.2020 10:37)
        
        Вот сразу понятна ущербность bool в виде избыточности. Вообще надо отказаться от лишней сущности и все сравнивать с 0. Все проще ровно в два раза, и это исходные подходы С, это потом развели костылей. - VLLV(21.09.2020 09:17)
        
        По ссылке обоснование. Ну да, не сказать, что очень убедительное >>> - SciFi(21.09.2020 09:39, ссылка)
        
        Я как-то боролся с непониманием определений состояний входов GPIO и стал определять только одно. А для логических выражений доля истины в обосновании есть. - VLLV(21.09.2020 10:24)
        
        Ага. Учту такой вариант. Оставить "как есть" не получается - предупреждения выползают. - teap0t(21.09.2020 01:03)
        
        С определенным и используемым из #include <stdbool.h> есть проблемы? - RxTx(21.09.2020 01:56)
        
        В учебном проекте эта библиотека не используется, но в одном из заголовочных файлов есть очень похожая запись. В проекте teap0t(255 знак., 21.09.2020 02:07)
        
        MISRA ругается потому что для безопасности они не рекомендуют пользоваться обще-генеральными типами int, long итд. Какую длину в байтах будут иметь эти типы зачастую предсказать тяжело и это ведет к ошибкам. Вместо этого они рекомендуют пользоваться встроенными типами у которых в точности известен размер: <inttypes.h> RxTx(1381 знак., 22.09.2020 20:27)
        
        MISRA2004 требует использования стандарта C89 (правило 1.1 обязательное). Я до него пока не дошёл (вернее дошёл, но там столько ошибок вылезает, что я опух слегка). Так что о типе bool придётся забыть. Если я правильно понимаю мисру, то конструкцию if (var) { она пропустит (правило 12.6 обязательное), только если var имеет логический тип (хотя в примере к правилу 16.9 даётся пример корректного кода if( func() ) {}). Тут непонятно, т.к. teap0t(395 знак., 22.09.2020 21:33)
        
        (x == y) - это логический тип, поэтому эти игрища с bool_TypeDef смысла не имеют. А по большому счету правило хорошее. - VLLV(22.09.2020 21:39)
        
        По-моему, мисра -- это не рекомендации. Это запреты в стиле гестапо. Шаг влево, шаг вправо -- расстрел. - SciFi(22.09.2020 20:27)
        
        Вся эта ржака с бешеными автомобилями началась отсюда: RxTx(48 знак., 22.09.2020 20:36, ссылка, ссылка)
        
        История с тоётой -- это про то, как америкашки япошек раскулачивали, ЕМНИП. - SciFi(22.09.2020 21:21)
        
        Причем я сталкивался с японским кодом (для игр) и как бы не удивляюсь, это очень характерно для японцев. Ну там годзиллы, тентакли, бродячие замки, хентай, лоликон, буккакэ... Они такие :))) - RxTx(22.09.2020 20:45)
      - Ну не факт, что оригинальные false/true намного лучше :) - VLLV(21.09.2020 00:42)

ARM, RISC-V контроллеры