Re: More C type errors by default for GCC 14

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Thu, 11 May 2023 at 00:18, James K. Lowden <jklowden@schemamania.org> wrote:
>
> 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.

That's not what the standard says.

>  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.

Technically, the standard only requires a diagnostic, and a warning is
a diagnostic. So strictly speaking, it's conforming to let them pass
with a warning. The question is whether that's really the best
behaviour for the majority of current users. At some point in the past
it was decided that warning and continuing by default was the best
choice. That might not still be true today.

> 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".

I don't think that actually matters here.

> 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.

Indeed.

> 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.

Well, no, because issuing a warning for violations of the spec
conforms to the standard. So it's not that simple, we really do have
to decide whether to actually cause compilation failure for these
constraint violations, or just issue a diagnostic and continue.