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

> From: Arsen Arsenović <[email protected]>
> Cc: [email protected],  [email protected],  [email protected]
> Date: Sat, 15 Aug 2026 10:44:38 +0200
> 
> > It wasn't broken back when Emacs 24.1 was released, or at least we
> > weren't aware of that.  It's only the latest GCC releases quite
> > arbitrarily decided that -std=gnu99 means to reject any program that
> > does not strictly conforms to C99.  Previously, -std=gnu99, unlike
> > -std=c99, always allowed useful deviations from the standard.
> 
> The latter sentence is interesting.  It implies that -std=gnu99 no
> longer permits a useful deviation from the standard, but that's simply
> not the case.
> 
> It no longer permits a certain deviation that was, through experience,
> seen to be far more harmful than useful.

IOW, you've redefined "useful" to suit the point you want to make.
How does this add any useful insights to this discussion?

> ISTM that you've decided that functionality which, as we've seen in wide
> experience, in 99/100, if not 999/1000, cases produced problems, not
> value, is useful.

It was there before, so removing it should be carefully considered, in
particular wrt use cases which it could break.

> How do you make that judgment without having either the broader
> experience of building tens of thousands of software releases for
> distros, or with dealing with GCC bug reports?

Again, it's an _existing_ feature.  Why it existed is much less
relevant than the fact that it does.  When removing features, their
existence should have overwhelming weight, just because they exist.
That is how we respect our users, at least in Emacs.

> But, to make an analogous hypothetical for sake of clarity, if Emacs was
> to change some default because you, a veteran Emacs developer, with
> consensus from other Emacs developers, saw that it has caused much more
> harm than good, and it happened to break some random Elisp script on my
> machine, that went untouched for 25 years, but helped a thousand people
> for each such script, would you expect me to use it as an example of the
> poor judgment, abandonment of principle, carelessness, and adversarial
> approach of you, a few years down the line?

YES!  When such changes are suggested for Emacs, there's no end to our
attempts to find a way to have the cake and eat it, too, so that we
don't break backward compatibility.  You can find many examples of
that on this list.  In many cases, when a solution that leaves both
cases satisfied cannot be found, we actually refuse to make the
change, even though the proposed new behavior is desirable.

> Would it be fair for me to say, in that scenario, "that the current
> attitude of many/most Emacs developers is at best downplaying the
> importance of being able to run old Elisp, and at worst is utterly
> hostile to the plight of people who for some reason need to do that"?

YES!!!

> I don't read debbugs for Emacs.  I don't maintain ELPA.  I don't
> maintain Emacs core.  How could I possibly allow myself to do that?

You can allow that because your legitimate use case was broken by a
change in Emacs.

> For instance, it may happen when lexical-binding becomes default.

Which is why we are moving towards that goal painstakingly slowly, in
tiny steps, each time leaving behind compatibility features and
waiting a very long time between such changes.  Several people brought
up suggestions to move faster and with bolder changes, but we
eventually decided not to do that.

> > This case is not necessarily relevant, I was responding to your
> > "blatant violation" claim.
> 
> What I was referring to there is specifically the lack of declaration as
> the blatantly wrong thing.

It was not wrong once upon a time.  And programs still worked and did
their jobs correctly.  Yes, that required the developers to be more
vigilant and find problems "by hand" rather than with help of the
compiler.  But that's a far cry from "blatantly wrong".

> >> libc has fairly few real breaks, for instance.
> >
> > It has enough, and the problem here is that glibc is a GNU project, so
> > it can be expected that it will avoid breaking Emacs, which is another
> > GNU project, at all costs.
> 
> I'm not sure that's reasonable to expect indefinitely.
> 
> For instance, was 'unexec' not impeding the development of malloc?

It was, but I cannot believe a solution couldn't have been found which
allowed it to work for years to come.

> Now that we have pdumper, should we still halt malloc development?

It was the other way around: the urge to develop pdumper was triggered
by the imminent threat of a breaking change in glibc.  Emacs builds on
new enough systems started segfaulting.

> I doubt you think that, since you were around when the support for
> 'unexec' was being removed.

We didn't yet remove it, officially.  Emacs 31.1, when released, will
remove it, years after pdumper was added to Emacs.

> That said, if there was to be some GNU-wide CI system or such that
> validated all changes against other GNU packages that are still
> considered "supported" (read: tested for by policy and automation),
> that'd be very useful for all.

We did tell the glibc developers that the hooks they intended to
remove were being used by Emacs, so the lack of such a CI system was
not the culprit here.  In most cases like this, the problems a
breaking change will cause are well known in advance.  The same was
true for the K&R syntax we are discussing.