> 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". > 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. > 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? 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. 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. > 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?
