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

> From: Arsen Arsenović <[email protected]>
> Cc: Eli Zaretskii <[email protected]>,  [email protected],  [email protected]
> Date: Thu, 13 Aug 2026 23:20:02 +0200
> 
> > Bug for bug is not what we’re talking about here. We’re talking about
> > „this caused problems so we broke all programs that relied on it“.
> 
> Thee are two remarks to add here:
> 
> 1. The class of programs that accidentally used these "features" that
>    were made errors by GCC 14, and thus had silent bugs introduced, is
>    vastly bigger than the class of programs that used them intentionally
>    and correctly.

That doesn't help to those who are in the second class.  It is IMO
wrong to break those on behalf of the first class, without leaving an
easy way out.  And that's even before we discuss the fundamental issue
whether it is at all the business of GCC to care what its users do.
It's IMNSHO okay to let users enough rope to hang themselves and treat
them as responsible adults that won't; those who actually do should be
amply rewarded by having their programs broken.  Why isn't that
enough?

> 2. The compiler was refusing to diagnose errors *even when the standard
>    dialect was specifically asked for*.

This is okay as the default; GCC has the -pedantic option for
countermanding that.

> As I covered in another post, SIGSTKSZ simply is not a constant in
> reality anymore, so if the value was to be bumped (which was suggested,
> and AFAIK done for the case when !_DYNAMIC_STACK_SIZE_SOURCE), it was
> liable to become too small again later, and thus any program that wasn't
> recompiled after the SIGSTKSZ value gets bumped would be liable to new
> crashes.

They could have gone an extra mile and provided a
backward-compatibility shim here.  For example, they could have left
SIGSTKSZ a compile-time constant, and introduced a new symbol, say
SIGSTKSZ2, which could use a dynamic definition.  This is the classic
backward-compatibility stance in our business, and I'm sure the glibc
developers knew about it.

> >> This is precisely how GCC was doing for decades (with -pedantic,
> >> -Werror=...  and -pedantic-errors).  These decades are overwhelming,
> >> rather than sufficient proof, that this approach is a dead-end.
> >
> > Decades of GCC being more and more successful and widespread.
> 
> Indeed.  That success and wide-spread use is why I am confident that
> these decades are overwhelming evidence that opt-in strictness via
> -pedantic utterly failed.

So accept that.  Users have spoken, and it is not the business of GCC
developers to second-guess them, let alone think you know better.

> Imagine how much better the software ecosystem would've been if all of
> that success and spread was accompanied with better diagnostics.

The majority is not always right, but it is always a majority.
Developers of programs should cater to the majority even if they
disagree with it, because these are our users, and they deserve the
respect even when they are wrong in our opinions.  This is what it
means to be user-friendly.

> > Just that when they were already lax by default, that should not be
> > changed.
> 
> Right.  And I'm writing against that.
> 
> On this specific point, the one that changed in GCC 14, the vast
> majority of instances were *not* intentional usages of K&R C syntax.  In
> most of these cases, they were serious bugs waiting to explode in
> someones' face.

And warning about that should have been enough, as the default.
Making that an error by default broke builds unnecessarily, the only
argument for that being that you want to forcefully "educate" your
users.

Anyway, I think we can roundup this discussion.  Ir clearly shows what
I initially said, and for which RMS asked for details -- that the
current attitude of many/most GCC developers is at best downplaying
the importance of being able to compile old source trees, and at worst
is utterly hostile to the plight of people who for some reason need to
do that.  The rest should be taken up with the GCC developers on their
lists, if at all; it no longer belongs to the Emacs-related forums.