有哪些非 ISO 实践的例子是 -pedantic 没有发现的？

Question

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html：

\n

\n

一些用户尝试使用它-Wpedantic来检查程序是否严格符合 ISO C。他们很快发现它并没有达到他们想要的效果：它找到了一些非 ISO 实践，但不是所有\xe2\x80\x94，只有那些 ISO C需要诊断的实践，以及其他一些已添加诊断的实践。

\n

\n

有哪些未发现的非 ISO 实践示例-pedantic？

\n

Answer 1

这里的问题从根本上来说是，编写的 C 程序可能包含错误（不仅仅是未能实现严格一致性），而要求 C 编译器检测是不合理的。在该标准最初编写时（1989 年），整个程序分析是不可能的，即使现在，它的成本也很高。人们总是能够构建像这样的结构

extern _Bool collatz_sequence_does_not_terminate(int);
int foo(int n) {
    int rv;
    if (collatz_sequence_does_not_terminate(n)) {
        return rv;
    }
    return 23;
}

其中“这个程序是否有未定义的行为”的答案取决于一个其解未知的数学问题。

因此，该手册试图警告您，不仅 GCC 无法检测到所有可能违反 ISO C 一致性的行为，而且没有编译器可以检测到。它的措辞有点太珍贵了，如果我还在 GCC 工作，我可能会修改它以使其更清晰。

如果您想要一个使程序不合格、根本没有诊断出来并且在现实生活中相对可能出现的情况的具体示例，请尝试以下大小：

/* a.c */
#include <stdint.h>
uint64_t val = 0x0123456789abcdef;

/* b.c */
#include <stdio.h>
extern double val;
int main(void) {
    printf("%g\n", val);
    return 0;
}

需要进行整个程序分析来检测两个文件之间的类型不匹配。这不是一个困难的案子；编译器可以用其类型注释每个全局符号，链接器可以检查每个符号的所有使用以确保与定义的一致性。但我不知道有任何工具链或静态分析产品可以检测到变量的此错误。