GNU bug report logs - #75451
scratch/igc: Enable CHECK_STRUCTS

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefankangas <at> gmail.com>

Date: Thu, 9 Jan 2025 03:58:02 UTC

Severity: wishlist

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Gerd Moellmann <gerd <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 75451 <at> debbugs.gnu.org
Subject: bug#75451: scratch/igc: Enable CHECK_STRUCTS
Date: Mon, 20 Jan 2025 09:54:28 -0800
Pip Cet <pipcet <at> protonmail.com> writes:

> Using "break" instead of "return" is impossible:
>
> * "default: eassume (0);"  means you lose compiler warnings if the enum is
> expanded.  -Wswitch-enum generates the compiler warnings, but they're
> lost in a sea of false positives because sometimes we cannot switch over
> an enum exhaustively.
>
> * "default: emacs_abort ();" will generate code to handle the "impossible"
> case
>
> * Omitting the default statement will make GCC treat the fall-through case
> as reachable
>
> This is because this code:
>
> #include <stdio.h>
>
> enum three { A, B, C };
>
> int main (void)
> {
>   volatile enum three four = C + 1;
>   volatile const char *bad = 0;
>   switch (four) {
>   case A:
>   case B:
>   case C:
>     printf ("%s\n", "good");
>     break;
>   default:
>     printf ("%s\n", bad);
>   }
>   return 0;
> }
>
> is treated by GCC as valid code and the "bad" printf cannot be
> determined to be unreachable.

I have no reason to doubt that you are correct, but what are the
consequences for us, in concrete terms, that make you say that "using
'break' instead of 'return' is impossible"?  Given that most programs
run just fine despite the shortcomings and/or bugs you have identified
in GCC, I think that saying using the switch statement in the normal way
is "impossible" might be overstating the case.

My apologies if I'm missing the point that you're making here.

BTW, has this been reported to the GCC developers?

> Let's introduce macros for the different cases, and use the same macro
> in the same case, until GCC offers a fix.

I'm with Gerd here, and not too excited about the prospect of yet
another macro.  I'd rather do without the additional warning, and just
have it crash at runtime instead, like we do now.

But are we sure that installing my patch would make things worse?
If I'm reading Paul correctly, he's saying that a static check is
more reliable.




This bug report was last modified 105 days ago.

Previous Next


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