More C type errors by default for GCC 14

[Eli Zaretskii]

> Date: Wed, 10 May 2023 14:03:01 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, fweimer@redhat.com,
>         gcc@gcc.gnu.org, arsen@aarsen.me
> 
> > > Why should this compile?
> > 
> > Because GCC is capable of compiling it.
> 
> That is not a good argument.  GCC is capable of compiling any code in all
> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
> mean those bugs shouldn't be fixed.

Fixing those bugs, if they are bugs, is not the job of the compiler.
It's the job of the programmer, who is the one that knows what the
code was supposed to do.  If there's a significant risk that the code
is a mistake or might behave in problematic ways, a warning to that
effect is more than enough.

> C99 for the above says:

I know what the standard says, but since when do we in the GNU project
accept standards as a dictate?  We do what we consider to be best for
our users, and follow the standards when that doesn't contradict what
we think is best for the users.  GCC has, for example, -std=gnu99
etc. precisely for that purpose.

> The proposal is essentially to stop accepting this as a GNU extension
> which was added for K&R compatibility I assume and do that only for C99 and
> later.

I understand.  I'm saying that there's no reason to make this an
error, because it will break builds that have good reasons for keeping
such code.

> Note, this isn't valid even in C89 and is already rejected with
> -pedantic-errors for years.

Terrific!  Rejecting such code given a non-default option is _exactly_
what should be done.  But we here are discussing the default behavior.

> > It compiles today with a warning, so that whoever is interested to fix
> > the code, can do that already.  The issue at hand is not whether to
> > flag the code as highly suspicious, the issue at hand is whether
> > upgrade the warning to errors.  So let's talk about the issue at hand,
> > not about something else, okay?
> 
> We do such changes several times a year, where we reject something that has
> been previously accepted in older standards, admittedly mostly in C++.

And that is a Good Thing?  I don't think so.  Maybe for C++ it's
inevitable, I'm not an expert on that.  But making breaking changes is
inherently BAD and should be avoided.

> Yes, it is done far less in C, but still, as the above is invalid already in
> C89, users had over 3 decades to fix their code, and in many cases they
> didn't and without this move they will never bother.

Please consider those cases where the code cannot be "fixed", in
practice.  I described one such situation in a previous message.

> A lot of such broken code has been even written in those 3 decades, doesn't
> predate it, but because the compiler just warned on it, it still appeared in
> the code bases.  If we wait with this change another 2 decades, nothing will
> change and we'll have the same problem then.

GCC is not responsible for the existence of that code.  So GCC
shouldn't change its decades-long behavior just because that code is
there.  there must be a much more serious reason for such changes,
something that affects GCC itself.