Re: More C type errors by default for GCC 14

[David Brown <david@westcontrol.com>]

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 <jakub@redhat.com>
>>> Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, arsen@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.gcc@gmail.com>
>>>>> Date: Tue, 9 May 2023 18:15:59 +0100
>>>>> Cc: Arsen Arsenović <arsen@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