Re: More C type errors by default for GCC 14

[David Brown <david@westcontrol.com>]

On 10/05/2023 16:39, Eli Zaretskii via Gcc wrote:
>> 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.

If gcc itself contains code that relies on outdated features, these 
should be fixed in the gcc source code.  It is one thing to suggest that 
a project that has been "maintenance only" for several decades cannot 
reasonably be updated, but that does not apply to current programs like gcc.

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

The suggestion has been - always - that support for old syntaxes be 
retained.  But that flag should be added to the makefiles of the 0.01% 
of projects that need it because they have old code - not the 99.99% of 
projects that are written (or updated) this century.

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

Do you have any reason to believe that the old code group is of relevant 
size?  I think it is quite obvious that I have been pulling percentages 
out of thin air, but can you justify claiming anything different?

I mean, if gcc simply added a default "-Werror=implicit" flag in the 
release candidate for gcc-14, how many people do you think would 
actually complain?  I'd guess that there would be far fewer complaints 
than there are posts in this thread discussing whether or not it's a 
good idea.


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

Again - did you miss the point about people who really want to work with 
old code can do so, by picking the right flag(s) ?

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

We cannot expect a /language/ with a 50 year history to be as safe as a 
modern one.  But we can expect a /compiler/ released /today/ to be as 
safe as it can be made /today/.

I agree that C is not the best choice of language for many people. 
Actually, I'd say that most people who program in C would be better off 
programming in something else.  And most programs that are written in C 
could be better in a different language.  But when C /is/ the right 
choice - or even when it is the choice made despite being the wrong 
choice, I want it to be /good/ C, and I want tools to help out there as 
best they possibly can.  That includes good default flags, because not 
all gcc users are experts on gcc flags.

My ideal, actually, would be that gcc has "-Wall -Wextra" by default, 
trying to help developers from the get-go.  It should also have an flag 
"-sep" that disables all warnings and uses lax modes, for people using 
it to build software provided by others and they want nothing to do with 
the source code.  But of course that is not the ideal situation for 
everyone else!

(See <https://en.wikipedia.org/wiki/Somebody_else%27s_problem> for an 
explanation behind the "-sep" flag.)


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

GCC currently provides the brush and the carpet lifter as standard 
equipment.  All we are suggesting is that these are not provided by 
default, and require extra effort to access.