【发布时间】:2014-12-17 14:22:54
【问题描述】:
我试图找出在测试 strict C90 一致性时要使用的 gcc 标志组合是什么。根据之前的帖子:GCC options for strictest C code?,我应该只需要一个--std=c90。
但这是我尝试过的:
$ cat t.c
#include <stdint.h> /* added in C99 */
int main()
{
uint64_t t;
return 0;
}
$ gcc -std=c90 -ansi -pedantic t.c
上述方法运行良好(没有产生警告/错误)。
有谁知道:
- gcc 标志具有严格的 ISO/IEC 9899:1990 一致性
- 具有不同标志集的不同编译器(tcc、clang...)?
编辑:
对不起我的措辞,是的,我真的很想模仿一个严格符合 C90 的编译器,换句话说,如果代码尝试使用以后添加的任何功能(想到 C99),它应该会失败。所以pthread 包含头文件应该 在以GNU/GCC calls C90 mode 编译时发出警告(就像 stdint.h 头文件应该在没有 C99 的情况下产生警告)。 -pedantic 很好地警告我long long 的使用,我不明白为什么它不应该警告我uint64_t。
我使用了 ISO/IEC 9899:1990 的术语,引用自:
1990 年,ANSI C 标准(带有格式更改)被 国际标准化组织 (ISO) 作为 ISO/IEC 9899:1990,有时也称为 C90。因此,术语“C89” 和“C90”指的是同一种编程语言。
EDIT2:
GCC 文档其实很清楚:
C99 标准中的某些功能被接受为 C90 模式下的扩展,以及 C11 中的一些功能 标准被接受为 C90 和 C99 模式中的扩展。
所以我的问题被改写为:
- 在 Linux 系统上是否有编译器 + 标准包含头文件,严格符合 C90?
【问题讨论】:
-
请注意,C90 是在 ISO/IEC 9899 标准中指定的。您要求 ISO/IEC 9945-1 是 POSIX 标准。
-
我还没有听说过允许你检查这个的编译器。一些编译器,例如 gcc 和 clang 以及 3.party 标准库,在相当长的时间内支持所请求的标准,特别是在语言级别,但它们并不意味着是合规检查器。对于库功能,它甚至更没有实际意义,因为 C 允许非标准库/头文件可用,没有什么能阻止实现在 c89 编译器中提供 stdint.h - 例如gcc 和 clang 不提供库/头文件 - 留给 3. 方(通常是 linux 上的 glibc)
-
你说应该发出警告,你的证据呢?梳理标准后,我看不到任何地方说需要编译器来发出诊断。
-
@malat
<stdint.h>中没有任何内容应该无法在 C90 模式下编译。允许实现为它不提供的相应类型省略任何类型定义/宏。如果您尝试在 C++03 中包含 C++11 标头,编译器本身不会发出诊断信息,而是 GCC 在标头文件中有#errorpragma。 -
我猜维护标头的人可以通过添加
#if (__STDC_VERSION__ < 199901 && __PEDANTIC__)之类的内容,然后向例如#error指令添加类似的东西来轻松实现这一点。stdint.h。然而,他们是否会这样做是值得怀疑的,因为我认为绝大多数用户并不真正需要该功能,而且他们可能不会为“以防万一”修补两打标题。当然,您可以随时尝试提交补丁。