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.
