Re: More C type errors by default for GCC 14

[David Brown <david.brown@hesbynett.no>]

On 10/05/2023 18:28, Eli Zaretskii via Gcc wrote:
>> Date: Wed, 10 May 2023 17:58:16 +0200
>> From: David Brown via Gcc <gcc@gcc.gnu.org>
>>
>>> 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.
> 
> I actually agree; we just have different definitions of "incorrect".
> 

Fair enough.

>> 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".
> 
> But we are not talking about some random code that just happened to
> slip through cracks as a side effect of the particular implementation.
> We are talking about code that was perfectly valid, had well-defined
> semantics, and produced a working program.  I don't care about the
> former; I do care about the latter.

How would you know that the code had perfectly valid, well-defined 
semantics?

I've had the dubious pleasure of trying to maintain and update code 
where the previous developer had a total disregard for things like 
function declaration - he really did dismiss compiler complaints about 
implicit function declarations as "only a warning".  The program worked 
as he expected, for the most part.  But that was despite many functions 
being defined in one part of the code with one set of parameters (number 
and type), and called elsewhere with a different set - sometimes more 
than one selection of parameter types in the same C file.

Insisting on proper function declarations and removing implicit int does 
not guarantee that such messes won't happen - but it /does/ reduce some 
of the opportunities to do so accidentally.

> 
>> 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.
> 
> You will have to explain this to me.  Just stating this is not enough.
> How will accepting K&R stop GCC development?
> 

People write incorrect code all the time.  Studies have shown that 
pretty much any sizeable C or C++ program - including gcc itself - 
contain undefined behaviour but rely on particular results from that. 
Lax interpretation and long outdated syntaxes do not, in themselves, 
imply undefined behaviour or incorrect code - but they make it far 
easier to accidentally have such errors, and to cover up such errors. 
(That's why they were removed in the first place.)

If a compiler is required to continue to compile every program that a 
previous version compiled, where the developer was satisfied that the 
program worked as expected, then the only way to guarantee that is to 
stop changing and improving gcc.

I agree that accepting fully correct programs written in K&R C would not 
limit the future development of gcc.  But how many programs written in 
K&R C, big enough and important enough to be relevant today, are fully 
correct?  I'd be surprised if you needed more than one hand to count 
them.  I would expect subtle errors and assumptions to flourish - with 
typical examples being signed integer arithmetic overflows and abuses of 
pointer casts and invalid mixing of pointer and integer types.

Continuing to give developers what they expect, rather than what the 
standards (and gcc extensions) guarantee, is always an issue for 
backwards compatibility.  Each new version of gcc can, and sometimes 
does, "break" old code - code that people relied on before, but was 
actually incorrect.  This is unavoidable if gcc is to progress.

That is why I suggested that a flag such as "-fold-code" that enables 
long outdated syntaxes should also disable the kind of optimisations 
that are most likely to cause issues with old code, and should enable 
semantics chances to match likely assumptions in such code.  I don't 
believe in the existence of correct K&R C code - but I /do/ believe in 
the importance of some K&R C code despite its errors.


> As for the two's complement wrapping example: I'm okay with having
> this broken because some useful feature requires to modify the basic
> arithmetics and instructions emitted by GCC in a way that two's
> complement wrapping can no longer be supported.  _That_ is exactly an
> example of a "good reason" for backward incompatibility: GCC must do
> something to compile valid programs, and that something is
> incompatible with old programs which depended on some de-facto
> standard that is nowadays considered UB.  

The problem for backwards compatibility and continuing to compile old 
code is that these things were /always/ UB - but they were, as you say, 
viewed as de-facto.

> But the case in point is not
> like that, AFAIU: in this case, GCC will deliberately break a program
> although it could compile it without adversely affecting its output
> for any other valid program.  To me, this would be an arbitrary
> decision of the GCC developers to break someone's code that has no
> "good reasons" which I could understand and respect, let alone accept.
> 

I think we have already agreed to disagree on what reasons count as 
"good" here, even though we agree that good reasons are required.

>> 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".
> 
> This is not the logical consequence, this is reductio ad absurdum, a
> kind of strawman.  There's no need to go to such extremes, because
> "good reasons" for breaking backward compatibility do exist.  I'm a
> co-maintainer of GNU Emacs, a program that attempts not to break
> habits of users burned into their muscle memories for the last 30
> years; don't you think I know a bit what I'm talking about?
> 

"Knowing what you are talking about" is not the same thing as being 
correct.  But I think our key disagreements here are a matter of 
opinion, not fact - "correct" is not an appropriate term for an opinion. 
  We are looking at things from a different viewpoint, which will 
naturally be coloured by our experiences.  So to be clear, I fully 
understand your opinion and viewpoint here - I just don't think it 
should be the philosophy for gcc going forward.

It is a good thing that we can express and exchange these opinions. 
Ultimately, I suppose it is the gcc steering committee that will decide 
(the length of this thread suggests it is too important for developers 
alone).  I don't know about you, but I know that /I/ have absolutely no 
say or vote in the process - I am not involved in gcc development. 
However, I think it is good that a wide variety of people are able to 
give their thoughts, ideas and opinions, and I hope it helps the people 
who will make the decisions in the end.