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

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?

I hate to get involved in this controversy again, which we already did
to death on the GCC mailing list, and maybe I shouldn't, but the insight
I have to offer is that GCC is no longer used at my organization in
consequence of attitudes towards users such as this, and the
impossibility of establishing the provenance of changes under a system
where "Developer Certificates of Origin" are permitted as warranties of
authorship.

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

As far as I recall, a solution was in fact found in the shape of
HYBRID_MALLOC and `gmalloc.c', which was required for unexec on some
other systems too.