Re: More C type errors by default for GCC 14

[Eli Zaretskii <eliz@gnu.org>]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: luangruo@yahoo.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org
> Date: Thu, 11 May 2023 21:25:53 +0200
> 
> >> This seems like a good route to me - it facilitates both veterans
> >> maintaining code and beginners just learning how to write C.
> >
> > No, it prefers beginners (which already have the warnings, unless they
> > deliberately turn them off) to veterans who know what they are doing,
> > and can live with those warnings.
> 
> Indeed.  I said facilitates, not treats equally.  I think the veterans
> here won't lose much by having to pass -fpermissive, and I think that's
> a worthwhile sacrifice to make, to nurture the new without pressuring
> the old very much.

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

> > The right balance is exactly what we have now: emitting warnings
> > without breaking builds.
> 
> I disagree - I think breaking builds here (remember, it takes 13 bytes
> to fix them) is a much lower weight than the other case being shot in
> the foot for an easily detectable and treatable error being made easily
> missable instead, so I reckon the scale is tipped heavily towards the
> veterans.

I described in an earlier message how this breakage looks in real
life, and why it causes a lot of frustration.  The main problem is
discovering that things broke because GCC defaults, and then
discovering how to pacify GCC with the least effort.  You are talking
only about what follows these two discovery processes, and that misses
the main disadvantage of this proposal (an in fact almost any breaking
proposal).

> On that note - lets presume a beginners role.  I've just started using
> GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
> mentions some 'implicit function generation', dunno what that means - if
> it mattered much, it'd have been an error.  I wrote a function called
> test that prints the int it got in hex, but I called it with 12.3, but
> it printed 1.. what the heck?
> 
> Why that happened is obvious to you and I (if you're on the same CPU as
> me), but to a beginner is utter nonsense.
> 
> At this point, I can only assume one goes to revisit that warning..  I'd
> hope so at least.

That's perfectly okay: the beginner made a mistake of ignoring a
warning, and now he or she will need to pay for that mistake.

But why should someone else pay, and pay dearly, for the mistakes of
such newbies?  That is simply unfair.  The payment should be on the
one who made the mistake.

> I doubt the beginner would know to pass
> -Werror=implicit-function-declaration in this case (or even about
> Werror...  I just told them what -Wall and to read the warnings, which
> was gleefully ignored)

They don't need to.  They just need to fix their bad code, that's all.

> Is it that much of a stretch to imagine that a maintainer of a codebase
> that has not seen revisions to get it past K&R-esque practices would
> know that they need to pass -std=c89 (or a variant of such), or even
> -fpermissive - assuming that they could even spare to use GCC 14 as
> opposed to 2.95?

If the program built okay till now, they might not know.

> As an anecdote, just recently I had to fix some code written for i686
> CPUs, presumably for GCC 4.something or less, because the GCC I insist
> on using (which is 13 and has been since 13.0 went into feature-freeze)
> has started using more than the GPRs on that machine (which lead to hard
> to debug crashes because said codebase does not enable the requisite CPU
> extensions, or handle the requisite registers properly).  I think this
> fits within the definition of 'worked yesterday, broke today'.

But it broke for a valid technical reasons: GCC was improved by
supporting more registers, and thus it now emits better code.  This
kind of reason is perfectly legitimate for breaking some old and
borderline-invalid programs, especially if GCC was emitting warnings
for those programs in past releases.

But the change discussed here is not like that.

> With all that to consider, is it *really* a significant cost to add
> -fpermissive?

See above (and my earlier message): the significant cost is to
discover the root cause of the problem, and that -fpermissive is the
solution.  The rest might be relatively easier, at least in some
projects.

> I expect no change in behavior from those that maintain these old
> codebases, they know what they're doing, and they have bigger fish to
> fry - however, I expect that this change will result in:
> 
> - A better reputation for GCC and the GCC project (by showing that we do
>   care for code correctness),
> - More new code being less error prone (by merit of simple errors being
>   detected more often),
> - Less 'cult knowledge' in the garden path,
> - More responsible beginners, and
> - Fewer people being able to effectively paint GNU and/or C/++ as the
>   backwards crowd using a error-prone technique of yesteryear.

These are not technical reasons in my book, they are PR stuff.
Breaking code that was building previously based on such reasons
should be unacceptable in any project that respects its users.

> Builds break.

Yes, and cars crash every day.  But we still consider car crashes to
be undesirable, and take measures to minimize that.  IOW, there's no
reason to be fatalistic about build breakage; we should instead
proactively try to minimize that.