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

Arsen Arsenović <[email protected]> Sat, 15 Aug 2026 20:10:54 +0200
Newsgroups	gmane.emacs.devel
Message-ID	<[email protected]>
Eli Zaretskii <[email protected]> writes:

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

No more than you have: it's a subjective judgment.

It can be made on the basis of user experience, of course.

Others, with more experience with GCC users than me or you have
concluded that what you consider ("redefine as", if you will) useful
here is more harmful than useful.

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

It was considered.

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

It still exists.

Just like the lexical-binding:nil cookie will continue to exist.
 
>> 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.

I don't think you're being frank here.  It's easy to be bold in face of
a hypothetical.

The example below demonstrates this.  You've "mov[ed] towards
[lexical-binding:t by default] painstakingly slowly", so you think it's
OK.  Yet, when an aged exception made for backwards compatibility is
reconsidered 20 (or more) years later, after a diagnostic has been
emitted for that scenario the entire time, you think that's not OK.

I can conjure up programs that will break after the lexical-binding
change.  Indeed, I can probably find programs that will break after that
change, rather than needing to construct one.

In both cases, the programming language implementation would've been
informing me about it for a period of time.

If anything, the C99 change is less severe, as programs written for
dynamic binding are harder to convert into lexical binding than pre-C99
programs are to convert into C99, because the latter fails with a
diagnostic and the former changes behaviour that's outside of any static
analysis machinery (for good reason; I don't blame anyone for that).

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

The K&R C diagnostics have been in place for C99 and newer since at
least 2004 (I don't have GCCs older than that on hand).  GCC started
emitting them without any flags set in 2015, when C11 became the default
dialect.  They only started being rejected by default in 2024, with a
way to get old behaviour back.

In fact, even back in 2004, there was a way to suppress those
diagnostics.  There still is.

Like with that change, the change of the lexical-binding default will,
should it happen, break programs.

Based on this, it seems to me that there's a double standard at play.

Changing the default of lexical-binding would be fine eventually, after
the due considerations Emacs developers put in, but changing the default
on the permissiveness of K&R C syntax, after the due considerations of
GCC developers put in, is not.

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

No, a program that called a function returning a pointer as if it was
returning an int was wrong once upon a time also, and would indeed break
sporadically on machines whee the sizes of integers and pointers differ,
even if we're lucky enough not to see it break in other ways.

Again, that's very narrowly what I was referring to.

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

Maybe, maybe not.

But pdumper shouldn't run into any such issue in the future, FWIW, so I
reckon that's solved now.

>> 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 didn't say otherwise.  I'll reword.

Emacs has for a number of years now used pdumper instead of unexec.  But
all of the releases that do not were broken by the libc change.

With that context, I asked: should malloc development have halted even
though pdumper was made?

(Yes, I know that would not have happened, but "will avoid breaking
 Emacs [...] at all costs" implies that it should have.  I doubt you
 mean that.

 This also seems very un-comradery; it implies that Emacs concerns
 should triumph over all others, and implies that Emacs specifically
 cannot be wrong in using other GNU tools.

 I think it's far more reasonable to consider all GNU software as
 developed together and intended for use with other contemporary pieces
 of GNU; by this model, it's perfectly valid to make a change across all
 of GNU to accommodate for a change in any single part of GNU.  That's
 what cooperation looks like.

 But, doing that means that a 2010 Emacs does not impede the development
 of 2020 libc, and that changes in the latter that break the former -
 but not 2020 Emacs - whichever class of breaks they belongs to, aren't
 worked against "at all costs", but assessed on a case-by-case basis,
 based on impact on not just the holy Emacs, but on all users.)

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

I was referring to 'libc' support.  I know it's still in tree in 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.

There are many programs besides Emacs, and many breaks (indeed, very
many) that aren't easily well-known.
-- 
Arsen Arsenović
signature.asc (application/pgp-signature, 418 B)