Противоречит ли правило 21.1 MISRA C:2012 правилу C11?
MISRA C:2012, Правило 21.1:
#defineand#undefshall not be used on a reserved identifier or reserved macro name.
Однако C11 позволяет определить, например, __STDC_WANT_LIB_EXT1__.
Пример:
#define __STDC_WANT_LIB_EXT1__ 1 /* violation of MISRA C:2012, rule 21.1 */
#include <stdio.h>
#ifdef __STDC_LIB_EXT1__
/* tmpfile_s is available */
#endif
Означает ли это, что правило 21.1 противоречит С11?
УПД. Любой проект, совместимый с MISRA-C, не может использовать Приложение K. Это связано с тем, что согласно MISRA C: 2012, Поправка 2:
Other than defining
__STDC_WANT_LIB_EXT1__to '0', the facilities of Annex K (Bounds-checking interfaces) shall not be used.
Единственная цель MISRA и других подобных стандартов — запретить то, что позволяет стандарт базового языка.
@n.1.8e9-где-мой-шарем. РЖУ НЕ МОГУ. Вы резко уменьшили его цель :) Хотя я склонен согласиться, когда речь идет конкретно о MISRA.
@ЕвгенийШ. хорошо, если ограничение языка не является целью, то это средство для достижения цели. В любом случае стандарт кодирования больше ничего не делает. Он просто не может делать ничего другого.
Возможно, этот вопрос неправильно сформулирован? В частности, не должен ли вопрос заключаться в том, противоречит ли MISRA сам в отношении Приложения K C11? Например, правило 21.1 не использует #define с зарезервированными макросами, но поправка разрешает #define __STDC_WANT_LIB_EXT1__ 0? Потому что в противном случае, конечно, MIRSA будет противоречить [так] стандартом C11, ограничивая доступ к неотъемлемым функциям языка.
@ Бармар Да, действительно. Одним из примеров является Правило 20.9, которое требует, чтобы все идентификаторы, используемые в управляющем выражении #if или #elif директив предварительной обработки, перед оценкой были #define. Однако стандарт C не требует этого, потому что «все остальные идентификаторы (включая лексически идентичные ключевым словам) заменяются на pp-номер 0» (C11, 6.10.1/4).
Смысл таких стандартов кодирования в том, чтобы заставить вас писать «более безопасный» код, ограничивая возможности используемого вами языка. Например. вы не должны зависеть от того, что неопределенные макросы заменяются на 0 по умолчанию — инициализируйте их явно.
Ответы 2
Оригинальный MISRA-C:2012 охватывает только C90 и C99.
Как вы, очевидно, сами узнали, MISRA C:2012 AMD2 в отношении совместимости с C11 в значительной степени запрещает все важные функции C11 (Правило 1.4 AMD2.30), включая интерфейс проверки границ приложения K.
Я совершенно не понимаю, зачем кому-то вообще #define __STDC_WANT_LIB_EXT1__ 1, не говоря уже о приложении, связанном с безопасностью. Интерфейс проверки границ получил много критики даже внутри комитета C WG14. Вам не нужно правило, чтобы сказать вам, что ему нет места в приложении MISRA C - здравый смысл поможет вам очень далеко.
Что касается правила 21.1, то смысл в том, что люди не должны бежать создавать свои собственные волшебные оболочки с неожиданным поведением в отношении стандартных библиотечных функций и т. д. Например, #define strcpy(dst, src) strcpy(src, dst) или подобное безумие макросов, которое люди, которым нравится изобретать свой собственный макрос «местного гаражного стандарта». языки могли бы придумать.
Re: «много критики даже внутри комитета WG14 C»: да, я знаю об этом. См., например, 1, 2, 3, 4 (поиск N1962).
В дополнение к этому ответу Правило 1.4 ограничивает использование новых функций, по поводу которых у MISRA есть опасения, но для которых еще не подготовлено более полное руководство. В следующем дополнении будут добавлены рекомендации по некоторым из этих новых функций, а общее ограничение (Правило 1.4) будет ослаблено.
@Andrew Будет ли поддержка C17/C18? Опасения по поводу использования _Generic, как я понял, заключались в том, что разные компиляторы по-разному обрабатывали квалифицированные типы, передаваемые в _Generic. Это было исправлено в C17, и тип, переданный в _Generic, теперь имеет удаленные квалификаторы: «Тип управляющего выражения — это тип выражения, как если бы оно подверглось преобразованию lvalue». Так что теперь это должно быть четко определено, и есть много ситуаций, когда _Generic можно использовать для повышения безопасности программы.
Следующее обновление (надеюсь) будет выпущено одновременно с выпуском Embedded World в июне. Это будет (опять же, надеюсь) включать руководство по _Generic. Правило 1.4 в AMD2 является заполнителем, чтобы разрешить функции C11/C18, которые не вызвали проблем, пока мы догоняем те, которые нуждаются в дополнительных указаниях... и по мере добавления новых указаний список правила 1.4 будет сокращаться.
PS: Если вы приедете на EW в Нюрнберге в июне, приходите и скажите «Привет!»
Несмотря на специфику вашего предполагаемого использования __STDC_WANT_LIB_EXT1__, Правило 20.1 направлено на предотвращение случайного или преднамеренного (повторного) определения зарезервированных макросов.
Любое (пере)определение предназначены разрешено посредством отклонения, которое требует от пользователя обоснования того, что он делает.
Если вы В самом деле хотите использовать Приложение K (и @Lundin уже объясняет причины, по которым вы, вероятно, не должны этого делать), вы можете сделать это, отклонив Правило 20.1, чтобы переопределить __STDC_WANT_LIB_EXT1__, и Правило 1.4, чтобы отменить действующее общее ограничение. Это отклонение потребует от ты показать, что вы понимаете проблемы с Приложением K и что ты делает для предотвращения сомнительного поведения.
В качестве сноски: текущая позиция рабочей группы MISRA C заключается в том, что ограничение в отношении Приложения K, вероятно, останется в силе, по крайней мере, до тех пор, пока рабочая группа 14 не договорится о дальнейших действиях.
Отказ от ответственности: см. профиль для моей принадлежности
Для стандартов кодирования нормально быть более строгими, чем позволяет базовый язык. Это не противоречие.