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

Arsen Arsenović <[email protected]> Sat, 15 Aug 2026 11:01:11 +0200
Newsgroups	gmane.emacs.devel
Message-ID	<[email protected]>
Eli Zaretskii <[email protected]> writes:
 
>> 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.

https://gcc.gnu.org/gcc-14/porting_to.html#errors-as-warnings

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

That's quite a false equivalence.

People generally don't trip over a pebble into hanging themselves.

People will trivially use these features by mistake and cause themselves
problems or cause everyone else problems.  Ones which are hard to later
find.

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

With respect to this question, -pedantic has no effect.  This was a
warning by default when -std=c99 or -std=gnu99 or higher are set since
at least GCC 3.4 (I do not have older releases of GCC on hand to check
them).

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

They probably did.  I couldn't find discussion on this issue to see why
they decided against taking that approach, or indeed whether they
contemplated it, so I can't really add any more information.

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

Have they?  I've seen no such speech.  I've, in fact, seen little
contemplation of the issue.

But, in that vein, can we use the current lack of contemplation of that
issue as proof that the "users have spoken" that this change was okay?

Counting the people I've discussed this problem with, or that
participated in discussions that I've observed relevant to this, more
agree than disagree with the change.

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

You say this in spite of it clearly not being so.

> Making that an error by default broke builds unnecessarily, the only
> argument for that being that you want to forcefully "educate" your
> users.

Is this not the reduction to absurdity you accuse me of?

The argument is based on the fact that, for years, instances of our
permissive stance on K&R C syntax was creating much more trouble than
useful effect.

I also never said anything about educating users.

The only context in which I've used the word "educate" is as the name of
a profession in which I had experience with bringing up new toolchain
users.  This experience showed that the behaviour GCC implemented was
purely harmful to them.

But those aren't the only group for which that goes; indeed most people
treated those warnings as errors that, for some reason, don't stop the
build process and which are, therefore, easy to miss.

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

-- 
Arsen Arsenović
signature.asc (application/pgp-signature, 418 B)