On Tue, 9 May 2023 23:45:50 +0100 Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote: > > We are currently using gcc 12 and specifying C11. To experiment > > with these stricter warnings and slowly address them, would we need > > to build with a newer C version? > > No, the proposed changes are to give errors (instead of warnings) for > rules introduced in C99. GCC is just two decades late in enforcing the > C99 rules properly! This, it seems to me, is the crux of the question. Code that does not conform to the standard should produce an error. Code that can be compiled correctly, per the specification, but might not be what the user intended, is a candidate for a warning. If the proposed changes catch true errors -- not just dubious constructs -- that were previously allowed, well, that's the price of progress. That's the compiler getting better at distinguishing between code conformant and not. Section 2.1 "C Language" of the manual states that, with no option specified on the command line, the default standard is -std=gnu17. Part of the proposal IIUC is to treat undeclared functions as an error. Function prototypes have been required afaik since c99. If that's correct, then letting them pass without error is a mistake for -std=c99 and above. As to the default, is anyone suggesting that gnu17 -- i.e., c17 with GNU extensions -- includes ignoring missing function prototypes? That to me would be an odd definition of "extension". The user who has old code that does not meet the c99 standard but Just Works nonetheless has a direct route to compiling that code without complaint: -std=c90. It says so right there in the fine manual. It's that simple. The code is either in spec and compiles without error, or it is not and does not. The only debate is over what "the spec" is, and what warnings the user might want for conforming code. --jkl
