Ошибка MISRA-C при инициализации массива структуры

(Привет, это новая учетная запись, поэтому я пока не могу использовать раздел комментариев, чтобы попросить дальнейших разъяснений, так что прошу прощения за длинный ответ)

Чтобы быть конкретным, это Правило 10.3 относится к MISRA-C: 2012 (последний стандарт), который является значительным улучшением по сравнению с предыдущими версиями, поскольку прилагается больше усилий для объяснения обоснования MISRA, а также многих других совместимых и несовместимых примеров.

Обоснование правила таково: поскольку C позволяет автоматически выполнять назначения между различными арифметическими типами, использование этих неявных преобразований может привести к непредвиденным результатам с возможностью потери значения, знака или точности. MISRA_C: 2012 имеет важную модель типов, которая помогает предупреждать, когда это может произойти.

Описания правил также включают исключения из правила. Для правила 10.3 одно исключение: Неотрицательное целочисленное постоянное выражение существенно знакового типа может быть присвоено объекту по существу беззнакового типа, если его значение может быть представлено в этом типе.

Непонятно, в какой именно строке и столбце ваш инструмент сообщает о нарушении (он должен). Лучший из инструментов также предоставит более подробную информацию о том, какая именно часть правила нарушается (например, если вместо 1 у вас было 128 в первом назначении 8-битному, инструмент должен быть очень точным об этом. ).

В любом случае я (и мой инструмент) не вижу здесь нарушения 10.3.

Поскольку это «разрешимое» правило, я был бы обеспокоен инструментом, если это критичный для безопасности код, помимо того факта, что он тратит ваше время.

Большинство инструментов позволяют подавить предупреждение и задокументировать причину (в данном случае это ошибка в инструменте).

Если поставщику вашего инструмента требуется дополнительная информация, вы можете опубликовать свой вопрос в дискуссионном форуме по адресу http://www.misra-c.com, чтобы получить официальный ответ и отправить его поставщику.

Хм, это правило сделает установку 8-битных регистров практически невозможной, поскольку арифметические операции выполняются как int или больше ( обычные арифметические преобразования). Еще одна причина отказаться от MISRA как стандарта кодирования.

Я предполагаю, что вам нужно привести каждое значение в инициализаторе к типу соответствующего поля. Но, как указывается в правилах, это все равно является нарушением.

Когда я использую PC-Lint для проверки правил Misra, мне часто приходится добавлять суффикс u к константам:

const NVMM_ConfigType NvmmCnf_Layout[6] =
{
   {  1u, 1u,   4u},
   {  2u, 3u,   4u},
   {  5u, 5u,  16u},
   { 10u, 1u,   4u},
   { 11u, 2u,  32u},
   { 13u, 1u, 100u},
};

Это исключает преобразование int в unsigned.

Если этого недостаточно, приводит:

const NVMM_ConfigType NvmmCnf_Layout[6] =
{
   { (uint8_t ) 1u, 1u, (uint16_t )  4u},
   { (uint8_t ) 2u, 3u, (uint16_t )  4u},
   { (uint8_t ) 5u, 5u, (uint16_t ) 16u},
   { (uint8_t )10u, 1u, (uint16_t )  4u},
   { (uint8_t )11u, 2u, (uint16_t ) 32u},
   { (uint8_t )13u, 1u, (uint16_t )100u},
};