More C type errors by default for GCC 14

[Gabriel Ravier]

On 5/10/23 14:36, Eli Zaretskii via Gcc wrote:
>> 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.

Are you seriously saying that no accepts-invalid bug should ever be 
fixed under any circumstances on the basis that some programmers might 
rely on code exploiting that bug ??


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