GNU bug report logs - #75964
Switching the Emacs build to -Wswitch-enum in src/

Previous Next

Full log

Message #65 received at 75964 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 75964 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: Switching the Emacs build to -Wswitch-enum in src/
Date: Sun, 02 Feb 2025 08:21:15 +0000

"Paul Eggert" <eggert <at> cs.ucla.edu> writes:

> On 2025-02-01 10:54, Pip Cet wrote:
>
>> I don't know which builds eunreachable () would actually be treated as
>> unreachable in.  All optimized builds?  Only builds that also omit
>> emacs_abort ()?  What about machines where there's a single byte
>> "abort" instruction?
>
> I thought eunreachable () would be equivalent to eassume (false), for
> the same reason unreachable () is equivalent to assume (false). If we
> change the meaning of eassume (false), eunreachable () would change to
> match.

But emacs_abort () isn't equivalent to eassert (false), and that's
always been confusing to me.  Perhaps it needs to be that way, though.

>>> As long as there's an Autoconfy way to tell whether the new GCC behavior
>>> is present we should be OK. This could be via a test program compiled
>>> with the relevant GCC options. If that approach works, it might be
>>> better to fold the new behavior into -Wswitch-enum.
>>
>> I don't think people will be very happy if we don't even try
>> understanding chained enums.  They're quite common.
>
> Not sure we're talking on the same wavelength. I was worried about a
> lesser problem: how 'configure' should detect whether GCC behaves as
> now, or behaves as you're proposing. I suspect such a configure-time
> test would be needed if we head in this direction.

I must have misread.  I was trying to say that rolling the enum-checking
behavior into -Wswitch-enum would be a bad idea because of chained
enums, in use by some people who don't know much about autoconf (such
as, erm, myself).

Is autoconf the best way to establish whether this warning exists and is
useful?  Do we need to know that, even, or can't we just enable
-Wswitch-enum and people live with what they get?  I honestly don't know
that, and if it increases the chances this code will be merged I'm happy
to change things!

>> I'm not sure whether you're suggesting to list only the remaining
>> "unfixed" (yes, yes, better name) files somewhere, or something else
>> that I don't understand :-)
>
> Oh, I was hoping that we'd just fix the files, so there would be no
> unfixed files and no need for makefilery to deal with unfixed files.

My preference, too, but I thought the per-file approach would seem less
aggressive to files like bidi.c: We've got to choose what to do there,
and artificially taking the "don't touch bidi.c, tell make not to pass
the switch there" option off the table seemed unwise to me.

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.