Re: More C type errors by default for GCC 14

[David Brown <david@westcontrol.com>]

On 10/05/2023 16:14, Eli Zaretskii via Gcc wrote:
>> Date: Wed, 10 May 2023 14:41:27 +0200
>> Cc: jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org,
>>   arsen@aarsen.me
>> From: Gabriel Ravier <gabravier@gmail.com>
>>
>>>>> Because GCC is capable of compiling it.
>>>> That is not a good argument.  GCC is capable of compiling any code in all
>>>> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
>>>> mean those bugs shouldn't be fixed.
>>> Fixing those bugs, if they are bugs, is not the job of the compiler.
>>> It's the job of the programmer, who is the one that knows what the
>>> code was supposed to do.  If there's a significant risk that the code
>>> is a mistake or might behave in problematic ways, a warning to that
>>> effect is more than enough.
>>
>> Are you seriously saying that no accepts-invalid bug should ever be
>> fixed under any circumstances on the basis that some programmers might
>> rely on code exploiting that bug ??
> 
> Sorry, I'm afraid I don't understand the question.  What are
> "accepts-invalid bugs"?
> 

They are cases where the C standards (plus documented gcc extensions) 
have syntax or constraint requirements, but code which breaks these 
requirements is accepted by the compiler.  For example, if the compiler 
accepted "long long long int" as a type, that would be an 
"accepts-invalid" bug.  They are important for two reasons.  One is that 
they mean the compiler fails to help the developer catch the mistake in 
their code.  The other is that the code might have an inconsistent 
interpretation, and that might change in the future.  In the 
hypothetical example of a three-long int, a current compiler might treat 
it as a "long long", while a future standard might add support for it as 
a new type with minimum 128-bit size.

> In any case, I was not not talking about bug-compatibility, I was
> talking about being able to compile code which GCC was able to compile
> in past versions.  Being able to compile that code is not a bug, it's
> a feature.
> 

No, being able to compile /incorrect/ code by default is a bug.  It is 
not helpful.

(The compiler cannot, of course, spot /all/ mistakes - the gcc 
developers are a smart group, but I think asking them to solve the 
Halting Problem is a bit much!)

I've seen this kind of argument many times - "The compiler used to 
accept my code and give the results I wanted, and now newer compiler 
versions make a mess of it".  The cause is almost invariably undefined 
behaviour, but it can occasionally be through changes to the standards 
such as removal of old behaviour or other differences in the 
interpretation of code (there were a number of incompatibilities between 
K&R and C90, and between C90 and C99).

The compiler is under /no/ obligation to compile undefined behaviour in 
the same way as it might have done for a particular piece of code.  It 
is under /no/ obligation to continue to accept incorrect or invalid 
code, just because it used to accept it.  It /is/ - IMHO - under an 
obligation to do what it can to help spot problems in code and help 
developers get good quality correct code in the end.  If it fails to do 
that, people will, and should, move to using different tools.

New compiler versions are not required to do two's complement wrapping 
of signed integer overflow, even though old broken code might have been 
written under the assumption that it did and even though older, less 
powerful versions of the compiler might have compiled that code into 
something the developer wanted.  In the same way, new compiler versions 
are not required to support syntax that has been dead for decades - at 
least not by default.  (Unlike most other compilers, gcc developers go 
far out of their way to support such outdated and incorrect code - all 
they ask is that people use non-default flags to get such non-standard 
syntax and semantics.)

If the gcc developers really were required to continue to compile /all/ 
programs that compiled before, with the same results, then the whole gcc 
project can be stopped.  The only way to ensure perfect backwards 
compatibility would be to stop development, and no longer release any 
new versions of the compiler.  That is the logical consequence of "it 
used to compile (with defaults or a given set of flags), so it should 
continue to compile (with these same flags)" - assuming "compile" here 
means "giving the same resulting behaviour in the executable" rather 
than just "giving an executable that may or may not work".

Clearly, you don't mean gcc development should stop.  That means a line 
must be drawn, and some code that compiled with older gcc will not 
compile with newer gcc.  The only question is where the line should be.