最強C代碼的GCC選項？

應該設置哪些GCC選項讓GCC儘可能嚴格？（我的意思是儘可能嚴格）我在C89編寫，並希望我的代碼符合ANSI/ISO。最強C代碼的GCC選項？

2012-01-20 TofuDeliverer

請嚴格遵守相關標準。 ANSI X3.159-1989和/或ISO/IEC 9899：1990，ISO/IEC 9899：1999或ISO/IEC工作組的「C1X」（http://www.open-std.org/JTC1/SC22/ WG14）（JTC1/SC22/WG14）。 ANSI C和ISO C90僅在標準本身的章節編號方面有所不同AFAIK – mctylr

@mctylr：「我在C89中編寫」似乎非常清晰。 –

嚴格地說，C89不符合ANSI/ISO標準。目前的ISO C標準是2011年發佈的標準;這也是目前的ANSI C標準; 1989年，1990年和1999年的標準已經過時。但這只是對措辭的一種狡辯;對於C89/C90仍然有廣泛的支持（比C99更多），即使它不再是官方標準，你仍然可以遵循它。 –

我推薦使用：

-Wall -Wextra -std=c89 -pedantic -Wmissing-prototypes -Wstrict-prototypes \ 
    -Wold-style-definition

你應該-O以及-g編譯一些警告是隻有在優化器使用（實際上，我通常使用-O3爲察覺的問題）可用。您可能更喜歡-std=gnu89，因爲這會禁用庫中較少的擴展名。 OTOH，如果你編碼嚴格的ANSI C89，也許你希望他們禁用。 -ansi選項相當於-std=c89，但不夠明確或靈活。

缺失的原型會警告您在使用（或外部函數定義）時沒有原型的函數。嚴格的原型意味着你不能在函數聲明或定義（或函數指針）中使用'空括號';您需要(void)或正確的參數列表。舊的樣式定義斑點ķ& [R風格定義，比如：

int old_style(a, b) int a; double b; { ... }

如果幸運的話，你將不再需要擔心。我在工作中並不那麼幸運，我也不能使用嚴格的原型，這讓我很懊惱，因爲周圍有太多懶散的函數指針。

另請參閱：What is the best command-line tool to clean up code

來源

2012-01-20 19:35:28

'-Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition'選項是一個好主意，但它們不符合標準的一致性。自1989年以來，舊式函數聲明和定義已經過時，但它們仍然是語言的一部分;即使符合C2011的編譯器也需要支持它們。 –

@Keith：你在閱讀時打開了'-pedantic'標誌：D是的，但我仍然推薦使用這些選項，以便代碼可以最大程度地向前移植到標準的更高版本。我不會驚訝地發現，C2021最終失去了對非原型功能的標準支持，雖然實現後可能會繼續支持舊的標記10 - 20年。 C11也消除了'gets（）';我不認爲它會長時間從圖書館消失。即使它完全符合C89，也應該避免。 –

我寫了一篇文章：http://shitalshah.com/p/how-to-enable-and-use-gcc-strict-mode-compilation/ – ShitalShah

這組選項是相當不錯的：

-Wall -Wextra -ansi -pedantic

你必須閱讀文檔，看看是否存在由該組合得到冷落任何額外的警告。

您應該警告嚴格的C89不包括對//樣式註釋的支持，並且對於具有外部鏈接的對象名稱中的重要字符數有一些相當嚴重的限制。

來源

2012-01-20 19:27:46

文檔說「-ansi -pedantic」應該爲你提供嚴格的ISO C90，並且會警告任何GNU C擴展（不僅僅是那些不兼容的）。如果你想要錯誤，你可以使用「-pedantic-errors」。雖然不是嚴格的問題，但您可以考慮「錯誤」，將警告轉化爲錯誤。儘管在哲學上「警告並非錯誤」 –

最強C代碼的GCC選項？

回答

相關問題