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

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pipcet <at> protonmail.com, 75964 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: bug#75964: Switching the Emacs build to -Wswitch-enum in src/
Date: Mon, 10 Feb 2025 15:26:16 -0800

On 2/8/25 23:29, Eli Zaretskii wrote:

> I have no objections to this patch, but it would be weird if bidi.c
> were the only C source file to use this technique.

Thanks, installed. Yes, other C source files will need similar patches, 
and I'll look into doing those. Once they're done, ./configure 
--enable-gcc-warnings can start enabling gcc -Wswitch-enum so that we 
get the extra static checking for enum switches that don't use INT_PROMOTE.


>>> getting UNKNOWN_BT there could mean one of the
>>> following:
>>>
>>>    . the UnicodeData.txt file used for building Emacs was corrupted or
>>>      incorrectly interpreted by our scripts
>>>    . admin/unidata-gen.el has a bug or was incorrectly adjusted to
>>>      changes in Unicode
>>>    . there's a bug in chartab.c code that deals with uniprop char-tables
>>
>> Yes, but if any of those things happen, couldn't one also get (say) -1
>> or 100 instead of 0?
> 
> Extremely unlikely, to say the least.

Fine, though I still don't understand why the likelihood for such a bug 
to result in 0/nil is so much greater than a bug resulting in (say) a 
negative number, that we should have an always-on runtime check for the 
former but not check the latter even when --enable-checking.

It's no big deal, though; perhaps we should give this subtopic a rest.


>> The change is not primarily about readability for each individual case.
>> That being said, it can help the human reader by giving the human an
>> easy-to-see visual cue that this 'switch' statement deliberately omits
>> some enum cases.
> 
> I prefer comments which say that explicitly.

I hope that the explicit comments in INT_PROMOTE's definition suffice, 
just as similar comments already suffice in the definitions of UNINIT, 
FALLTHROUGH and similar macros. Just as I would prefer not to attach a 
"/* Pacify gcc -Wmaybe-uninitialized. */" comment to every use of 
UNINIT, I'd prefer not to do something similar for every use of 
INT_PROMOTE, FALLTHROUGH, etc.

Previous Next

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