[英]MISRA-C error in struct array initialization
我有以下內容:
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]表達式的值不得分配給具有較窄基本類型或不同基本類型類別的對象
我試圖弄清楚為什么會這樣,但我只能看到它。 在類似的情況下,構建結果也會受到這種錯誤的困擾,我不知道為什么。
有人知道發生了什么嗎?
編輯:我也嘗試顯式轉換每個值仍然得到相同的錯誤:
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},
};
(嗨,這是一個新帳戶,所以我還不能使用評論部分要求進一步澄清,所以請原諒長篇回復)
具體而言,本規則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},
};
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.