On 09/05/2023 22:13, David Edelsohn via Gcc wrote:
On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc <gcc@gcc.gnu.org>
wrote:
Date: Tue, 9 May 2023 21:07:07 +0200
From: Jakub Jelinek <ja...@redhat.com>
Cc: Jonathan Wakely <jwakely....@gmail.com>, ar...@aarsen.me,
gcc@gcc.gnu.org
On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
From: Jonathan Wakely <jwakely....@gmail.com>
Date: Tue, 9 May 2023 18:15:59 +0100
Cc: Arsen Arsenović <ar...@aarsen.me>, gcc@gcc.gnu.org
On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
No one has yet explained why a warning about this is not enough,
and
why it must be made an error. Florian's initial post doesn't
explain
that, and none of the followups did, although questions about
whether
a warning is not already sufficient were asked.
That's a simple question, and unless answered with valid arguments,
the proposal cannot make sense to me, at least.
People ignore warnings. That's why the problems have gone unfixed for
so many years, and will continue to go unfixed if invalid code keeps
compiling.
People who ignore warnings will use options that disable these new
errors, exactly as they disable warnings. So we will end up not
Some subset of them will surely do that. But I think most people will
just
fix the code when they see hard errors, rather than trying to work around
them.
The same logic should work for warnings. That's why we have warnings,
no?
This seems to be the core tension. If developers cared about these issues,
they would enable appropriate warnings and -Werror.
-Werror is a /big/ stick. An unused parameter message might just be an
indication that the programmer isn't finished with that bit of code, and
a warning is fine. An implicit function declaration message shows a
clear problem in the code - a typo in the function call, a missing
#include, or a major flaw in the design and organisation of the code.
The C language takes backwards compatibility more seriously than any
other programming language. When the C standards mark previously
acceptable features as deprecated, obsolescent, or constrain errors, it
is done for very good reasons. People should not be writing code with
implicit int, or non-prototype function declarations. Such mis-features
of the language were outdated 30 years ago.
The code using these idioms is not safe and does create security
vulnerabilities. And software security is increasingly important.
The concern is using the good will of the GNU Toolchain brand as the tip of
the spear or battering ram to motivate software packages to fix their
problems. It's using GCC as leverage in a manner that is difficult for
package maintainers to avoid. Maybe that's a necessary approach, but we
should be clear about the reasoning. Again, I'm not objecting, but let's
clarify why we are choosing this approach.
There are two problems I see with the current state of affairs, where
deeply flawed code can be accepted (possibly with warnings) by gcc by
default.
1. Modern developers who are not particularly well versed in the
language write code with these same risky features. It is depressing
how many people think "The C Programming Language" (often a battered
first edition) is all you need for learning C programming. Turning more
outdated syntax and more obvious mistakes into hard errors will help
such developers - and help everyone who has to use the code they make.
2. Old code gets compiled with with modern tools that do not fulfil the
assumptions made by the developer decades ago. Compiling such code with
modern gcc risks all sorts of problems due to the simpler compilation
models of older tools. For example, the code might assume two's
complement wrapping arithmetic, or that function calls always act as a
memory barrier.
My suggestion would be to have a flag "-fold-code" that would do the
following (at a minimum) :
* Disallow higher optimisation flags.
* Force -fwrapv, -fno-strict-aliasing, -fno-inline.
* Require an explicit "-std=" selection.
* Allow old-style syntax, such as implicit int, with just a warning
If the "-fold-code" is /not/ included, then old, deprecated or
obsolescent syntax would be a hard error that cannot be turned off or
downgraded to a warning by flags. A substantial subset of -Wall
warnings would be enabled automatically. (I think the "unused" warnings
should not be included, for example.)
Distributions and upstream code maintainers should be pushed towards
either fixing and updating their code, or marking it as "-fold-code" if
it is too outdated to modernise without a major re-write. This might be
painful during the transition, but waiting longer just makes the
situation work.
(I'm a long-term gcc user, but not a gcc developer. I'm fully aware
that I am asking others to do a lot of work here, but I think something
of this sort is important going forward.)
David
