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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 75964 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: Switching the Emacs build to -Wswitch-enum in src/
Date: Sat, 1 Feb 2025 23:46:30 -0800

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.

Currently, if !ENABLE_CHECKING, eassume (false) is equivalent to 
unreachable (). And ENABLE_CHECKING, eassume (false) is equivalent to 
(suppress_checking ? unreachable () : die (...)). I was thinking that 
eunreachable () would do the same. That is, if we change the die (...) 
to __builtin_abort () or emacs_abort () or whatever, that would affect 
both eassume and eunreachable.


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

Previous Next

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