我正在使用 IAR Embedded Workbench 編譯器，但遇到了 with 優先級#pragma問題#if。
我#if 0在開發程序中使用注釋掉代碼。
下面#pragma的代碼是為了抑制有關在 C 字串中使用十六進制轉義序列的 MISRA 問題。
代碼片段：
#if 0
// Display the glyphs in the font.
// This is debug code.
#pragma diag_suppress=Pm118,Pm003
static const char * text[] =
{
// Limit rows to 20 characters.
" () -0123456789Vanot",
"y^?",
"\xE3\x81\x84" "\xE3\x81\x8A" "\xE3\x81\x8C",
};
#pragma diag_default=Pm118,Pm003
static const size_t quantity_text_lines =
sizeof (text) / sizeof(text[0]);
uint16_t y = 150U;
for (unsigned int i = 0u; i < quantity_text_lines; i)
{
cmd_text_convert(35U, y,
FONT_HEADING_HANDLE,
0u,
text[i]);
y = 60u;
}
#else
在上面的代碼片段中，我遇到了錯誤：
Error[Pm118]: hexadecimal escape sequences shall not be used (MISRA C 2004 rule 4.1)
我的理解是我不應該收到任何警告，因為代碼在一個#if 0塊內。
僅供參考，當我更改#if 0為時#if 1，沒有錯誤，也沒有生成警告。
IAR 編譯器的行為是否正確？
關于語言標準的裁決是什么？
（環境實際上是C語言，但也可以用C 編譯。）
uj5u.com熱心網友回復：
標準說#pragmas 應該被忽略，這與你看到的一致。（錯誤訊息未被抑制。）
6.10.1p6：……按順序檢查每個指令的條件。如果它的計算結果為假（零），則跳過它控制的組：指令僅通過確定指令的名稱進行處理，以跟蹤嵌套條件的級別；其余指令的預處理標記被忽略，組中的其他預處理標記也是如此。
（所以#pragmainside#if 0唯一被檢查的部分是 token pragma，并且只檢查它是否影響條件嵌套。）
問題是編譯器是否可以為預處理標記引發標記化錯誤。我會說它不應該，但是標準中沒有任何內容可以阻止編譯器在感覺時生成診斷。這是一個實施質量 (QOI) 問題，取決于消費者的心血來潮，而不是標準委員會。
無論如何，MISRA 不是標準的一部分。
uj5u.com熱心網友回復：
IAR 編譯器的行為是否正確？
編譯指示或無編譯指示，IAR 通過對塊的內容執行 MISRA 一致性分析的行為令人驚訝#if 0，如果這確實是它正在做的事情。這似乎與 C 前處理器語意不一致。程式文本——或者更準確地說，預處理標記——在條件評估為零的條件指令之后僅被處理到足以識別匹配的#elseor #endif，否則被忽略。
可能 IAR 的 MISRA 掃描器旨在忽略前處理器條件，或者測驗每個選項的兩種選擇。如果它確實這樣做了，那么它的行為令人驚訝，因為它無法識別那些它會在它們之外識別的條件塊內的編譯指示。
我懷疑@rici正確地假設該問題已由 IAR 的源標記器標記，然后由于相關#pragmas 被忽略（按照語言規范的指示）而沒有被抑制。但這在 IAR 的控制范圍內。我很難接受這樣的論點，即 IAR 可以自由地實施 MISRA 合規性掃描，但不能自由地擴展前處理器行為以正確支持相關的基于 pragma 的控制。或者就此而言，它不能在適當的情況下讓前處理器條件直接控制 MISRA 一致性分析。
然而，
關于語言標準的裁決是什么？
C 語言規范沒有為所討論的 pragma 定義任何特定意義，也沒有為 MISRA 合規性檢查定義任何程序或語意。它指定必須為違反約束發出診斷，但不限制實作可能發出的診斷。這就是為什么我在上面將 IAR 的行為描述為令人驚訝而不是錯誤的原因。我可能會稱它為錯誤，但不是因為不符合語言規范。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/418561.html
標籤：