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.
