On 2025-02-02 11:27, Eli Zaretskii wrote:

> What are the problems in etags.c this tries to solve?

The main point is to catch more potential inadvertent omissions of "case 
X:" in a "switch (E)" where E's type is an enum containing X. etags.c, 
like the rest of Emacs, currently uses one style to do this; the 
proposed style would be better at catching these mistakes.

Although the proposed style is shorter than what Emacs currently uses, 
brevity is not the main goal here.


> "switch (+expr)" has the disadvantage that it is not widely known.

It is a simple combination of two widely-known constructs, "switch (E)" 
and "+E". It is not a GNU extension: support for this has always been 
required by the C standard and it works everywhere.

If we use this style consistently it will be obvious, and gcc 
-Wswitch-enum will report inadvertent deviations from it which will be 
better than what we have now (no static checking). Also, developers who 
don't like the style won't be obliged to use it: they can use other 
techniques (already discussed) to pacify -Wswitch-enum if they prefer.


> Why would we want to use a construct that people
> might not be familiar with?

Because when we add -Wswitch-enum, GCC will be more likely to catch 
trivial mistakes that it doesn't currently catch.


> I'm not sure shortening etags.c by 23 lines justifies this.

The main goal here is reliability via better static checking, not 
brevity. Pip Cet's proposal to improve reliability makes the code more 
verbose, which is a minus. This proposal does not have that minus - on 
the contrary, it makes code shorter and simpler.

To test this again, I applied the style to the file that Pip Cet said 
was a troublesome case: src/bidi.c. Here the style made the code only a 
little bit shorter, but that was because I took the liberty of also 
improving the already-existing dynamic checking, as I modified 
bidi_get_type to also abort if default_value is not listed in the 
bidi_type_t enum. So this patch improves dynamic checking (without 
significant runtime cost), improves static checking, and makes the code 
a bit shorter and easier to read.

All in all it's a success story.