More C type errors by default for GCC 14
Wed May 10 13:30:02 GMT 2023
On 10/05/2023 14:22, Eli Zaretskii via Gcc wrote:
>> From: Jonathan Wakely <email@example.com>
>> Date: Wed, 10 May 2023 12:49:52 +0100
>> Cc: David Brown <firstname.lastname@example.org>, email@example.com
>>> 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
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
>> 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
> 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.
More information about the Gcc