Re: More C type errors by default for GCC 14

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 10 May 2023 17:08:18 +0000
> From: Joseph Myers <joseph@codesourcery.com>
> CC: Jakub Jelinek <jakub@redhat.com>, <gabravier@gmail.com>,
> 	<jwakely.gcc@gmail.com>, <fweimer@redhat.com>, <gcc@gcc.gnu.org>,
> 	<arsen@aarsen.me>
> 
> On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
> 
> > That is not the case we are discussing, AFAIU.  Or at least no one has
> > yet explained why accepting those old K&R programs will adversely
> > affect the ability of GCC to compile C2x programs.
> 
> At block scope,
> 
>   auto x = 1.5;
> 
> declares x to have type double in C2x (C++-style auto), but type int in 
> C89 (and is invalid for versions in between).  In this case, there is an 
> incompatible semantic change between implicit int and C++-style auto.  

So in this case, I'm okay with GCC changing the default behavior at
some point, such that the above is interpreted as C2x mandates, which
will then break some old programs.  This is another example of a "good
reason" for changing behavior in backward-incompatible ways.

But please note that emitting an error is not required, at least in my
book.  I assume GCC emits a warning about this already, and that
should be enough, until such time as you decide to adopt the C2x
interpretation of that by default -- without going through the
intermediate stage of erroring out by default.

> Giving an error before we make -std=gnu2x the default seems like a 
> particularly good idea, to further alert anyone who has been ignoring the 
> warnings about implicit int that semantics will change incompatibly.

FWIW, I don't see a reason to give an error.

> Enabling some of -Wall by default (as warnings, not errors) might well 
> also be beneficial to users, though case would be needed to exclude those 
> warnings that involve stylistic choices (e.g. -Wparentheses) or have false 
> positives that are hard to fix - not all of -Wall is for code that is 
> objectively suspicious independent of the chosen coding style.

IMO and IME, anything is better than errors.  I presume everyone on
this list is familiar with the frustrating experience of having a
large program suddenly fail to build with some strange-looking error
message, which launches you down the rabbit hole of trying to
understand what happened and why.  And if that happens as part of
running the configure script (as I understand is one of the potential
victims of that), that is even scarier, because most people don't read
the configure script and don't always understand what is going on
there and why; it is also not very easy to debug.

So I urge the GCC developers to try to avoid errors as much as
possible, as long as GCC is capable to produce code with some widely
adopted semantics, and break backward compatibility only if otherwise
GCC will be unable to implement newer features.  (And to be pedantic,
I don't consider new warnings to be new features in this context.)