Re: Discussion about why GNU/Linux system upgrades cause old programs to break

Arsen Arsenović <[email protected]> Wed, 02 Sep 2026 00:00:04 +0200
Newsgroups	gmane.emacs.devel
Message-ID	<[email protected]>
Hi Arne,

"Dr. Arne Babenhauserheide" <[email protected]> writes:

> [[PGP Signed Part:No public key for DCCF0DB30BC10548 created at 2026-09-01T13:59:39+0200 using RSA
> No public key for 13EF8D452403C3EB created at 2026-09-01T13:59:39+0200 using RSA]]
> Arsen Arsenović <[email protected]> writes:
>
>> Richard Stallman <[email protected]> writes:
>>
>>> But as long as the user keeps running it on the same 32-bit platform,
>>> which is quite likely to happen, it is not a bug in a concrete,
>>> practical sense.  On that same 32-bit platform, the program would
>>> never fail, except artificially if a newer GCC version refuses to
>>> compile it.
>>
>> It is only possible to expect a bug remaining "abstract" if you never
>> change any piece of the system the bug is "abstract" in.
>
> Yes. And by changing the compiler to fail the compile in a situation in
> which the program previously worked (where the bug was abstract), you
> add a condition that breaks a working program.

That is, indeed, changing the system.

That said, again, I do not agree with this "abstract" vs. "non-abstract"
dichotomy, and I find "program previously worked (where the bug was
abstract)" to be an oxymoron.

The bugs that you're deeming "abstract" are just bugs that at the given
moment are not noticed.

There's no reason to expect that to stay so when the compiler updates.

If you want something to be reliable, you cannot approach reliability
with a "prove it fails" approach, you must take a "prove it will always
work" approach.

Again, as I said in my last response to you, permitting users to rely on
false assumptions creates these problems.  Indeed, a wrong has been
committed by the compiler in this situation: the wrong of permitting the
"abstract" bug to be written.

At any rate, as I've stated numerous times, *literally nothing was
lost*.  It is entirely possible, and trivial, to recover old behaviour.


And, to clarify, obviously, a C compiler will never be able to prevent
all, or even most, or even many "abstract" bugs.  The source code for a
C program simply does not contain enough information to prove
automatically that the program is correct, or even to diagnose a giant
class of common errors.

C is particularly bad in this regard, especially because its type system
is terrible.  Obviously, no language will be able to prevent bugs in all
cases, but many languages do *far* more to prevent bugs than C can,
without significant downside, by providing better type systems among
other things.

There are cases where GCC can find issues with programs that C does not
consider errors.  In these cases, GCC emits warnings.

What we're discussing here is *the exact opposite*: a case where GCC's
dialect of C was made *even worse* than general C.

It was a departure from C for sake of backwards compatibility, and the
departure was diagnosed from what appears to be day one (but I do not
have old enough builds of GCC to check that, so it may not have been day
one).

That departure was made over 20 years ago.  At the time, it might even
have been justified (though, I am not sure it was, since -std=c99 was
not made default).

20 years later, the "backwards compatibility" is with a vanishing subset
of programs given to gcc.  999/1000 cases where this backwards
compatibility departure triggers are, in fact, legitimate errors.

Thus, the default was flipped.  And no functionality was lost.

I am getting rather tired of repeating this.

> Practical example where such bites:
>
> - You have to update a library because it has a critical vulnerability
> - The new library version requires a rebuild (I remember when libpng
>   did) and uses new language features, so you have to update the compiler
> - The new compiler version errors out when compiling your program

This is precisely the case in which the more insidious manifestations of
these "abstract" bugs may arise.

If the user is making false assumptions, the compiler will break them on
an update.  You cannot expect otherwise.

It is not possible for the compiler to read the mind of the developer to
see what they were assuming (wrongly).

> Now you have to patch your program instead of quickly updating the
> library and recompiling. If the sysadmins do the update, they may even
> have to call in someone from the dev-team to check the compiler error.
> This can (greatly) increase the time window in which your system is
> vulnerable (or offline, if you’re more careful).
>
> Without the compiler change the re-compiled program would have worked
> on this system without problems.

No.  That's simply not guaranteed.  Without more details, we cannot be
sure of that.

It may well be the case, but, again, experience shows that, more often
than not, programs that fall in these ways *were* wrong.

To mirror and counter your point: without the compiler change to
*permit* these malfeatures, the program would have worked on that system
*and other systems* without problems.

Perhaps this problem would've never happened had the decision not been
made to permit implicit function declarations and other malfeatures in
C99 mode way back when.

Though, they were never permitted silently, so there's that, at least.
-- 
Arsen Arsenović
signature.asc (application/pgp-signature, 418 B)