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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Andrea Corallo <acorallo <at> gnu.org>, eggert <at> cs.ucla.edu,
 75964 <at> debbugs.gnu.org, stefankangas <at> gmail.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#75964: Switching the Emacs build to -Wswitch-enum in src/
Date: Sun, 02 Feb 2025 14:13:49 +0200

> Date: Sun, 02 Feb 2025 11:48:45 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: eggert <at> cs.ucla.edu, 75964 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> 
> So while I'd like us to keep those options in mind, I've removed them
> from the following diff.  The idea is this would give an overview over
> which code segments would become hard to read as a result of such a
> change, and whether it's bad enough that we need to look at
> alternatives.
> 
> I think this concerns bidi.c and keyboard.c in particular.
> 
> I've marked some places where I'm not sure the old behavior was okay,
> but I haven't checked them in detail.  I haven't found any "there was a
> bug here and we only caught it because of this new warning" smoking
> guns.

Hmm... like I envisioned, where the list of enum values hiding behind
'default' is longer than half a dozen or so, the result looks really
problematic: a long and hard-to-read list of values without any
promise that it's exhaustive.  (I realize that the compiler will flag
any missing values, but when I read code, I prefer not to compile it,
and besides, it could not be in a compilable shape at that point).

Humans are not good when they need to deal with long lists, which is
why when the list gets long, it is easier to list values not in the
list.

So I wonder if we could find a better way, or perhaps decide that
where we need such long lists, we could do it the old way.

Btw, does eassume compile to emacs_abort in a production build (i.e. a
build without --enable-checking)?  If not, then perhaps this
replacement is not always a good idea?  We (should) use emacs_abort
when the code has no way of dealing with some situation, so letting
the execution continue past that point will sometimes crash or corrupt
data in ways that are much harder to debug than an abort.

Previous Next

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