Re: More C type errors by default for GCC 14

[David Brown <david@westcontrol.com>]

On 10/05/2023 14:22, Eli Zaretskii via Gcc wrote:
>> From: Jonathan Wakely <jwakely.gcc@gmail.com>
>> Date: Wed, 10 May 2023 12:49:52 +0100
>> Cc: David Brown <david@westcontrol.com>, 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?  (I realise I am 
asking you to be speculative and generalise.  This discussion is an 
exchange of opinions, thoughts, experiences and impressions.)

Frankly, the most common "good" reason for a developer not changing 
their code from pre-C99 is that they retired long ago.  And people 
should definitely question whether the code should be kept.

As I noted in another post, it is entirely reasonable to suspect that 
such old code has errors - unwarranted assumptions that were considered 
appropriate back in the days when such code techniques were considered 
appropriate.  It has always been the unfortunate case with C programming 
that getting optimal results for some compilers has sometimes involved 
"cheating" a bit, such as assuming wrapping signed arithmetic or 
converting pointer types and breaking the "strict aliasing" rules.

Changing the gcc defaults and requiring old code to use flags that allow 
old constructs but limiting optimisations is not /punishing/ the old 
code or its developers or maintainers.  It is /supporting/ it - allowing 
it to be used more safely with modern tools.


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)?  Why should they have to deal with other 
people's code that was badly written 30 years ago?  Is it really worth 
it, just so that a half-dozen maintainers at Linux distributions can 
recompile the 40-year old source for "ed" without adding a flag to the 
makefile?


Ultimately, /someone/ is going to suffer - a compiler can't have good 
defaults for current developers and simultaneously good defaults for 
ancient relics.  The question to consider is not whether we "punish" 
someone, but /whom/ do we punish, and what is the best balance overall 
going forward.


>>
>> There will be options you can use to continue compiling the code
>> without changing it. You haven't given a good reason why it's OK for
>> one group of developers to have to use options to get their desired
>> behaviour from GCC, but completely unacceptable for a different group
>> to have to use options to get their desired behaviour.
>>
>> This is just a change in defaults.
> 
> A change in defaults that is not backward-compatible should only be
> done for very good reasons, because it breaks something that was
> working for years.  No such good reasons were provided.  

I'm sorry, but I believe I /did/ provide good reasons.  Granted, they 
were in more than one post.  And many others here have also given many 
good reasons.  At the very least, making a safer and more useful 
compiler that helps developers make better code is a good reason, as is 
making a C compiler that is closer to standards compatibility by default.

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


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

Yes, it /is/ a good reason.  But I suppose that one is a matter of opinion.

I encourage you to look at CERT/CC, or other lists of code errors 
leading to security issues or functional failures.  When someone writes 
poor code, lots of people suffer.  Any initiative that reduces the 
likelihood of such errors getting into the wild is not just good for gcc 
and its users, it's good for the whole society.

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.  Rust 
code is written in modern development styles, with a care for 
correctness rather than getting maximum efficiency from limited 
old-fashioned tools or macho programming.  The only reason there is any 
sense in re-writing old programs in Rust is because re-writing them in 
good, clear, modern C (or C++) is never going to happen - even though 
the results would be as safe or safer.

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.


>> Accepting broken code by default is not a priori a good thing, as
>> you seem to insist. Rejecting it by default is not a priori a good
>> thing. There is a pragmatic choice to be made, and your argument is
>> still no more than "it compiles today, so it should compile
>> tomorrow".
> 
> 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.

Remember, when people wrote that old code, they didn't know the future 
of C, of compilers, of computers.  Maybe the code was not broken at the 
time, but times have changed.


>>>> Agreed.  But if we can make it harder for them to release bad code,
>>>> that's good overall.
>>>
>>> I'm okay with making it harder, but without making it too hard for
>>> those whose reasons for not changing the code are perfectly valid.
>>> This proposal crosses that line, IMNSHO.
>>
>> Where "too hard" means using a compiler option. Seriously? This seems farcical.
> 
> This goes both ways, of course.  GCC had -Werror since about forever.
>