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: Thu, 13 Aug 2026 22:43:55 +0200
> 
> > First, Emacs 24 was not a C99 program.
> 
> Then its build system broken.  It passes -std=gnu99 to the compiler when
> given a C89 compiler.

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.

> > We switched to C99 in Emacs 25.1, see NEWS.25.  So no, the above was
> > not a violation of the C standard we were adhering to back then,
> > certainly not a "blatant" violation.  I'm old enough to remember the
> > old C rules, whereby a function without a prior declaration
> > (a.k.a. "prototype") had very specific semantics for its return type.
> 
> Those semantics are wrong for this case

This case is not necessarily relevant, I was responding to your
"blatant violation" claim.

> thereby demonstrating what I said: a program that runs into these
> errors is very unlikely to be correct.

It was correct at the time Emacs 24.1 was released.

> The guessed function declaration has an int return type, as I'm sure you
> know, but the return type is char*.
> 
> This may accidentally work on IP32 machines, but it does not work on any
> other system, including mine.

That wasn't what happened back when Emacs 24.1 was released, or we
would have fixed this.  See below.

> > And second, I don't really understand the above warnings at all,
> > because emacsclient.c in Emacs 24.1 says this starting at line 232,
> > way before line 1606:
> >
> >   char *get_current_dir_name (void);
> >
> >   /* Return the current working directory.  Returns NULL on errors.
> >      Any other returned value must be freed with free.  This is used
> >      only when get_current_dir_name is not defined on the system.  */
> >   char*
> >   get_current_dir_name (void)
> >   {
> 
> That's under a preprocessor condition which, when unmet, also obscures
> the declaration above it.
> 
> When it is unmet, the definition is in another TU and no declaration
> exists in this TU.

Which probably means glibc changed where this function is declared,
because the preprocessor condition which hides the prototype was
supposed to cover the cases where the included header file, where this
function was expected to be declared, didn't declare it.

> >> Unfortunately, that's not at all a simple answer, especially not for an
> >> old codebase.  If I kept attempting to fix the above, I'm sure I'd have
> >> ran into many more problems.
> >
> > I'm sure you would.  And I would naïvely ask: why shouldn't we have an
> > easily-discoverable option to avoid such problems when we need to
> > compile old source code?
> 
> There's no such thing as an "easily-discoverable option to avoid such
> problems".

Of course, there is: have the GCC manual include index entries that
cite the messages emitted by the compiler, or their parts.

> If there was, people wouldn't fix it by pinning versions in the way I
> described before.

IMO, it isn't GCC's business to second-guess what the user wants or
needs to do with the options.  Its manual should cater to any
real-life situations, including those which perhaps go against your
opinions.

> That said, for the particular case of the GCC 14 changes, which were
> under discussion but are *not* what I was referring to above, I think
> making -fpermissive or -std=gnu89 easier to find would be good.  I'm not
> sure how best to go about it, though.

See above for one idea.

> >> I certainly expect Emacs compiled with fewer dependencies to live for
> >> longer, because that means, by proxy, that it is smaller.
> >
> > That's impractical to expect.
> 
> What I said is certainly not wrong to expect, but I think there's a
> misunderstanding, because, ...
> 
> > People expect Emacs to do everything including coffee, so most of the
> > users want as rich Emacs as possible, not as lean as possible.
> 
> ... is indeed true.
> 
> I didn't suggest that Emacs should be lean by default.  I also didn't
> suggest arbitrarily reducing program size as a solution.
> 
> What I said is that Emacs compiled with fewer dependencies (and thus
> with fewer features, and thus with less code) is less likely to break.

That's true, but it's unlikely to help in practice, for the reasons I
mentioned (and you agreed).  People build Emacs with as many features
as they can, and then need this very Emacs to keep working after many
system upgrades.  This is the situation we are discussing.

> > And anyway, some compatibility problems are in system libraries such
> > as libc and basic GUI stuff, and those dependencies cannot be removed
> > from Emacs.
> 
> Indeed, but obviously the fewer there are, the fewer breaks happen.
> 
> 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.  Ironically, the MS-Windows C runtime and
basic GUI libraries provide much better backward compatibility than
glibc and other system libraries on GNU/Linux do, and that somehow
doesn't make me proud.