MISRA錯誤10.1複雜整數的隱式轉換

我在MISRA規則下編寫代碼。我得到一個錯誤MISRA爲以下表達式MISRA錯誤10.1複雜整數的隱式轉換

check_Val =（〜（0x000Fu < < Src_Data））; //其中Src_Data是uint8，check_Val是uint32。

我分析了錯誤

違反MISRA 2004必需細則10.1，復整數表達

由於check_Val是uint32時，LF應該適合在其上的隱式轉換。那爲什麼它給出了一個錯誤。

什麼工具給你這個輸出？ – amdixon

可能重複的[Bitshift和整數推廣？]（http://stackoverflow.com/questions/3482262/bitshift-and-integer-promotion） –

@TomTanner如果它根本沒有提到MISRA，它怎麼可能是重複的？ – Lundin

通過使用MISRA：2004「基礎類型」的概念，即表達式的預期類型，規則10.1涉及隱式提升整數。這是一個奇怪的概念，導致無數的多餘演職人員，這已在MISRA：2012中得到修復。

表達式的基礎類型是整數文字0x000Fu的基礎類型。對於整數文字，它指出基礎類型是能夠表示對象的最小可能類型（參見p40-41）。所以0x000Fu的基本類型將是uint8_t，因爲它可以適合一個字節並且是無符號類型。

儘管就C語言和編譯器而言，該整數文字實際上是unsigned int類型，並且不會發生促銷活動。 MISRA：2004年不在乎。

這意味着您必須在操作之前將操作數投射到uint32_t（繞過規則10.1），或者在操作之後將其轉換爲uint8_t（對於轉換爲10.1和10.5）。我建議你把它投到uint32_t來擺脫這個問題。因此

固定碼應該是

check_Val = ~((uint32_t)0x000Fu << Src_Data);

此外，由於移位運算的兩個操作數都整數促進，右手操作者被隱式地提升到int爲好。這種提升永遠不會造成傷害，我不確定它甚至是MISRA違規，但我想這也可能會引起警告。在這種情況下，你也必須投右邊的操作數：

check_Val = ~((uint32_t)0x000Fu << (uint32_t)Src_Data);

我會建議使用MISRA：2012如果可能的話，在這些規則已經澄清和「基礎型」的概念已經取而代之的是不會導致如此多毫無意義的演員陣容。

2015-10-05 14:21:14 Lundin

'UINT32_C（0xF）'？ – EOF

@EOF對不起，什麼？ – Lundin

這是一種指定適當大小和值的常數的方法。雖然它顯然創建了「uint_least32_t」類型的值而不是「uint32_t」，所以我不確定MISRA會接受它。 – EOF

回答