Hacker News Reader

Comment by stevefolta | Hacker News Reader

> I thought GCC (or C itself) has good backward compatibility, but it's not sufficient.

Ha! It's been a long time since GCC was even able to compile older versions of _itself_.

Par for the course honestly. Obviously major C compilers are only becoming more strict about acceptable code. For instance when -fno-common was made the default in GCC 10 it ended up breaking an rather incredible number of packages.

Setting stricter defaults makes sense, but not being able to compile older code even with options to disable checks seems like a regression.

GCC supports a plethora of ISO standards, language extensions, pragmas, etc. It simply isn’t tractable to guarantee support for every behavior or language construct which GCC has tacitly supported. Compilers like GCC may go above and beyond the ISO C standards, but they aren’t in the business of supporting every C dialect possible.

Years of language-lawyering really refined our own understanding of what is and isn't correct code. Any older code is just so full of UB that they can barely be said to be valid code.

It's just a product of the times.

That's besides the point. The latest release of, let's say Linux, has bugs in it (statistically, unless it's the first perfect bug-free release ever). Would it be reasonable for a compiler to refuse to compile it? The compiler's job isn't to refuse to compile bad code if it could compile it, only to warn the user and try to help fix it if possible.

The problem isn't that the compiler chooses not to compile something if it deems it broken. The problem is that the broken code's behaviour is coupled to the compiler of the time.

The behaviour you want isn't "compile this version of Linux even though it has a bug", it's "compile this version of Linux as if you were a compiler at the time which accepted this broken code in this way", which is a very tall order, along the lines of bug-for-bug compatibility while also fixing the bug.

GCC 2.95 was a tremendously sticky release. The 3.x series was notorious for compiler bugs for a long time so many people stayed with 2.95 for years. I think a good number of people ended up skipping the entire 3.x release.

I vaguely recall that when I was building LFS some time in the past, gcc 2.95 was recommended over the 3.x series for some reason. So I looked it up and found a line about it in an old version of the book:

> This is an older release of GCC which we are going to install for the purpose of compiling the Linux kernel in Chapter 8. This version is recommended by the kernel developers when you need absolute stability. Later versions of GCC have not received as much testing for Linux kernel compilation. Using a later version is likely to work, however, we recommend adhering to the kernel developer's advice and using the version here to compile your kernel.

https://www.linuxfromscratch.org/museum/lfs-museum/5.0/LFS-B...

I wish I had a better reference. The bit about "compile this version of Linux as if you were a compiler at the time which accepted this broken code in this way" made me think of that.

Maintaining bugwards compatibility is a pain in the arse and eventually you really just have to cry havoc and let slip the dogs of breakage.

For code that has undefined behavior, the compiler may refuse to compile it or compile it into literally anything.

A common mistake is expecting code that has undefined behavior to be compiled into something that makes logical sense.

You may disagree with it but that’s how compilers work and how the standard describes they should work.

Reply on news.ycombinator.com