>> 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. Ouch?@!#*/-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.