Re: More C type errors by default for GCC 14

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 10 May 2023 15:30:02 +0200
> From: David Brown via Gcc <gcc@gcc.gnu.org>
> 
> >>> If some developers want to ignore warnings, it is not the business of
> >>> GCC to improve them, even if you are right in assuming that they will
> >>> not work around errors like they work around warnings (and I'm not at
> >>> all sure you are right in that assumption).  But by _forcing_ these
> >>> errors on _everyone_, GCC will in effect punish those developers who
> >>> have good reasons for not changing the code.
> 
> What would those "good reasons" be, in your opinion?

For example, something that adversely affects GCC itself and its
ability to compile valid programs.

> On the other hand, continuing to accept old, outdated code by lax 
> defaults is punishing /current/ developers and users.  Why should 99.99% 
> of current developers have to enable extra errors to catch mistakes (and 
> we all make occasional mistakes in our coding - so they /should/ be 
> enabling these error flags)?

Adding a flag to a Makefile is infinitely easier than fixing old
sources in a way that they produce the same machine code.

> I do agree that backwards compatibility breaks should only be done for 
> good reasons.  But I think the reasons are good.

Not good enough, not for such a radical shift in the balance between
the two groups.

> > And no,
> > educating/forcing GCC users to use more modern dialect of C is not a
> > good reason.
> > 
> 
> Yes, it /is/ a good reason.

Not for a compiler.  A compiler is a tool, it is none of its business
to teach me what is and what isn't a good dialect in each particular
case.  Hinting on that, via warnings, is sufficient and perfectly
okay, but _forcing_ me is not.

> Consider why Rust has become the modern fad in programming.  People 
> claim it is because it is inherently safer than C and C++.  It is not. 
> There are really two reasons for it appearing to be safer.  One is that 
> the /defaults/ for the tools, and the language idioms, are safer than 
> the /defaults/ for C and C++ tools.  That makes it harder to make 
> mistakes.  The other is that it has no legacy of decades of old code and 
> old habits, and no newbie programmers copying those old styles.

Exactly.  We cannot reasonably expect that a compiler which needs to
support 50 years of legacy code to be as safe as a compiler for a
language invented yesterday afternoon.  People who want a safe
programming environment should not choose C as their first choice.

> So yes, anything that pushes C programmers into being better C 
> programmers is worth considering, IMHO.  We will never stamp out bad 
> programming, but we can try to help them - giving them better tools that 
> help them spot problems early is a step forward.

I agree, I'm just saying that warnings are helpful enough -- for those
who want to be helped.

> > Once again: it isn't "broken code".  It is dangerous code, and in some
> > cases unintentionally suspicious code.  But it isn't broken, because
> > GCC can compile it into a valid program, which, if the programmer
> > indeed meant that, will work and do its job.
> 
> Sweeping problems under the carpet and hoping no one trips over the 
> bumps is, at best, pushing problems down the road for future developers.

I'm not sweeping anything.  This is not GCC's problem to solve, that's
all.  If the developer avoids dealing with this problem, then he or
she might be sweeping the problem under the carpet.  But this is not
GCC's problem.