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

Question

я следующее:

typedef struct 
{ 
    uint8_t BlockID; 
    uint32_t Copies; 
    uint16_t Size; 
}NVMM_ConfigType; 

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

Что выглядит хорошо для меня, но, MISRA-C дает следующее сообщение об ошибке:

MISRA C: 2012 правила Нарушение 10.3: [R] Значение выражения не присваивается объекту с более узким существенным типом или другой категорией существенного типа

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

Кто-нибудь знает, что происходит?

EDIT: Я также попытался явно привести все значения и по-прежнему получать ту же ошибку:

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

Когда я использую PC-Lint, чтобы проверить правила Мишра, я часто ловлю себя на необходимости добавить 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}, 
};