[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jiri Slaby from comment #7)
> (In reply to Martin Liška from comment #2)
> > Note there's a similar issue I sent patch for:
> > https://lore.kernel.org/all/f70c7a11-e81e-f6b9-a403-315117f4aa3a@suse.cz/
> 
> ? I.e. how to %-format "B" in your example for both gcc-12 (c == 4) and
> gcc-13 (c == 8).

Just be consistent in the enumerator types within the same enum.
If you intend the whole enum to be int and its enumerators too,
use values that fit into int or cast the values explicitly to int.
So enum E { A = (int) 0xffffffff, B = -2 }; etc.
Or if you want the whole enum to have some other type (unsigned int, long,
unsigned long, long long, unsigned long long), use similar casts and/or
constant suffixes.
enum E { A = 0xffffffffU, B = -2U, C = (unsigned) 0xfffffffd } to get unsigned
int for everything, etc.

As written by Joseph in the commit log for PR36113 fix,
"This change was previously requested in PR 36113; it seems unlikely that
people are depending on the detail of the previous extension that some
enumerators had different types to others depending on whether their values
could be represented as int, and this patch makes the change to types of
enumerators unconditionally (if that causes problems in practice we could
always make it conditional on C2x mode instead)."
So, we have a proof that at least some projects (parts of Linux kernel) do rely
on this detail, now the big question is how often does this happen in the
kernel and if it affects anything else.  If it is widespread, as Joseph noted,
it could be restricted to C2X.  But you'll run into it when you switch to C2X
one day...