cgccisostandards-compliancegcc-pedantic

What are the examples of non-ISO practices, which are not found by -pedantic?


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

Some users try to use -Wpedantic to check programs for strict ISO C conformance. They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all—only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added.

What are the examples of non-ISO practices, which are not found by -pedantic?


Solution

  • The problem here is fundamentally that it's possible to write C programs containing errors (not just failures to achieve strict conformance) that it is not reasonable to demand a C compiler detect. At the time the standard was originally written (1989), whole-program analysis was out of the question, and even now, it's expensive. And one will always be able to gin up constructs like

    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;
    }
    

    where the answer to "does this program have undefined behavior" depends on a mathematical problem whose solution is unknown.

    So the manual is trying to warn you, not just that GCC can't detect all possible violations of ISO C conformance, but that no compiler can. It's worded a little too preciously, if I still worked on GCC I might revise it to be clearer.


    If you want a concrete example of something that makes the program nonconformant, isn't diagnosed at all, and is relatively likely to come up in real life, try this on for size:

    /* 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;
    }
    

    Whole-program analysis is required to detect the type mismatch between the two files. It's not a difficult case; the compiler could annotate each global symbol with its type and the linker could check all uses of each symbol for consistency with the definition. But I'm not aware of any toolchain, nor any static analysis product, that will detect this error for variables.