Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

[Paul Eggert]

>> C11 is not incompatible with C99, the way that C99 was incompatible with C89.
> 
> That sounds like a description why the autoconf 2.70 change of putting 
> the compiler into the highest possible mode in AC_PROG_CC could break 
> existing software?

This doesn't sound likely either.  There are very few ways that C99
broke C89 programs.  And these are unlikely to appear in real-world
software.  How much real-world code looks like this?

    int N = (1//* this sets N to 1 in C99, and to 0 in C89.  address@hidden/-2
             + (INT_MAX < INT_MIN));

Here, gcc by default has the C99 behavior, as this is
what -std=gnu90 specifies, even though it's incompatible with C90
aka C89.  I hope this helps to explain why real-world code rarely
if ever runs into these incompatibility issues.

The transition that *did* break a lot of programs was the transition
from K&R C to C89.  And here, Autoconf took the strong stand of
putting the compiler in C89 mode by default.  With a TODO item that it
should be doing later versions of C too.  So there's a pretty strong
precedent for going with the more-recent version of C, even if that
might break things.

> The CC="gcc -std=gnu99" is needed in my example, it is not a part of the 
> scenario when the compiler defaults to C99 - which is neither for gcc 
> nor for other compilers that implausible.

Yes, that's plausible.  But having '-std=gnu11' break things doesn't
sound plausible.

> you need:
> - autoconf >= 2.70 and
> - a compiler old enough to not know the C11 value of __STDC_VERSION__

It's not a question of 'old enough'.  It's a question about how
compilers typically behave.  My impression, based on past experience,
is that __STDC_VERSION__ is often wrong.

> So autoconf is now trying an option that will fail the test with the 
> current compiler, and will likely be deprecated

Perhaps we should back off on how many C11 features we're checking, so
that IBM XL C V12.1 passes too?  That might be more useful.