Re: More C type errors by default for GCC 14

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 12 May 2023 10:15:45 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: Arsen Arsenović <arsen@aarsen.me>, luangruo@yahoo.com,
>         jwakely.gcc@gmail.com, gcc@gcc.gnu.org
> 
> On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> > 
> > Let's keep in mind that veterans are much more likely to have to deal
> > with very large programs than newbies, and so dealing with breakage
> > for them is much harder than doing that in a toy program.  Thus, the
> > proposal does "pressure the old very much".
> 
> Pressure for something they should have done decades ago if the code was
> really maintained.

Why not assume that at least some of them didn't because they had good
reasons?

> Anyway, I don't understand why these 3 (implicit fn declarations,
> implicit ints and int-conversions) are so different from anything that
> one needs to change in codebases every year as documented in
> gcc.gnu.org/gcc-NN/porting_to.html .  It is true that for C++ there are
> more such changes than for C, but say GCC 12 no longer accepts
> computed gotos with non-pointer types, GCC 10 changed default from
> -fcommon to -fno-common for C which also affects dusty codebases
> significantly, GCC 9 changed the lifetime of block scope compound literals
> (again, affected various old codebases), GCC 5 broke bad user expectations
> regarding preprocessor behavior by adding extra line markers to represent
> whether certain tokens come from system headers or not, etc.
> And of course compiler optimizations added every year can turn previously
> "working" code with undefined behaviors in it into code not working as user
> expected.  E.g. compared to the above 3 that are easily fixed, it is obvious
> what the problem is, tracking undefined behavior in code even when one
> has sanitizers etc. is much more time consuming.

The difference, IMO, is that in all the cases you describe the changes
were done because they were necessary for GCC to support some new
feature, or fix a bug.  By contrast, in this case there's no new
features that require to fail to compile the code in question.

> Can we stop this thread.  I'm afraid everything has been said multiple
> times, it is up to the GCC Steering Committee to decide this if there is
> disagreement on it among GCC developers, but my current understanding is
> that that is not the case here and that the active GCC developers agree on
> it.

Fine, I will stop posting at this point.  Thanks for listening.