More C type errors by default for GCC 14

[Gabriel Ravier]

On 5/12/23 08:25, Eli Zaretskii via Gcc wrote:
>> Date: Thu, 11 May 2023 18:43:32 -0400
>> Cc: luangruo@yahoo.com, gcc@gcc.gnu.org
>> From: Eli Schwartz <eschwartz93@gmail.com>
>>
>> On 5/11/23 2:24 AM, Eli Zaretskii wrote:
>>
>>> Back to the subject: the guarantees I would personally like to have is
>>> that the current GCC development team sees backward compatibility as
>>> an important goal, and will try not to break old programs without very
>>> good technical reasons.  At least in Emacs development, that is the
>>> consideration that is very high on our priority list when making
>>> development decisions.  It would be nice if GCC (and any other GNU
>>> project, for that matter) would do the same, because being able to
>>> upgrade important tools and packages without fear is something users
>>> value very much.  Take it from someone who uses GCC on various
>>> platforms since version 1.40.
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
> They are not technical, no.  Leaving the current behavior does not
> technically hamper GCC and its users in any way -- GCC can still
> compile the same programs, including those with modern std= values, as
> it did before, and no false warnings or errors are caused when
> compiling programs written in valid standard C.

The current behavior hampers GCC's users in very significant ways: it 
encourages people who are new to the language to write completely broken 
code in ways that should have been at least slightly harder to 
accomplish since a quarter of a century ago.

Arguing that GCC should compile any "valid standard C" seems like an 
obviously flawed premise to me given that unless you're going the 
strictly conforming route, a "program" such as:

]iN$<\J3"`q
Tf;9ge0k\hm[
!Zsr>MtiV B@
~x?M\A):.s0^W
2$((g]'Vx:jZ
D'?n/X_li|;E
aLA%WQmzNq-(QG'
r"rSV3|]k_BU?R
p:hPWg_(]Y(
And,3xD{iR5B

may be considered by any implementation as a valid standard C program, 
since it does not contain an #error directive.

Such examples may seem like hyperbole to you, but to a beginner, the 
constructs that you wish to leave usable in GCC unaltered may well be 
just about as confusing as you might find any interpretation of the 
valid standard C program presented above to be.

You may not be aware of this, but the current behavior leads to endless 
instances of beginners accidentally using utterly broken constructs and 
then coming to C forums/channels/etc. asking for help, only for people 
like me to discover that such code is still compiled by GCC now without 
anymore than a warning being given to the user (which they extremely 
commonly ignore). Having been on such forums for years, I'd estimate 
that this actually represents a genuinely significant proportion of the 
problems I help diagnose - about 10% or so (though I have of course not 
made a detailed study of every problem I've ever helped solve, but I'm 
relatively confident 10% is not too far from the real proportion). To be 
honest, it's such a common problem that I'm genuinely surprised it 
hasn't spawned off jokes in the same way things like 
T_PAAMAYIM_NEKUDOTAYIM in PHP have (I guess "implicit function 
declaration" has less of a ring to it than T_PAAMAYIM_NEKUDOTAYIM)

>
> The reasons are basically PR: better reputation for GCC etc.  Maybe
> even fashion: Clang does that, so how come we don't?
>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
> I already did, in previous messages, where I described what we all are
> familiar with: the plight of a maintainer of a large software system
> whose build suddenly breaks, and the difficulty in understanding which
> part of the system's upgrade caused that.  I'd rather not repeat that:
> there are already too many repetitions here that make the discussion
> harder to follow.