[Bug c/94142] typeof enum member appears to give wrong signedness

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Matthew Fernandez from comment #0)
> This seems surprising to me. Shouldn't x and y have the same signedness as
> they're both the type of the enum? It seems like somehow the type of an enum
> member differs from the type of the enum itself.

Because that's what C says:
"The identifiers in an enumerator list are declared as constants that have type
int"

So as the warning tells you, y has type int. Which is because A has type int,
so __typeof__(A) is int, i.e. not the same as t.

As documented at
https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
your enumeration type has an underlying type of unsigned int, because it has no
enumeration constants with negative values.

Although your example has no enumeration constants that could cause a problem,
this similar example shows a case where the warning is correct:

typedef enum { A, B, C = -1u } t;
t x = C;
__typeof__(A) y = -1;

int main() {
  if (x == y)
    return 0;

  return 1;
}

This causes an implicit conversion that alters the values, which is ecactly
what -Wsign-compare is designed to warn about.

> Some cursory testing suggests to me this behaviour extends back to at least
> the GCC 4 series. I could not find a version of Clang that has this
> behaviour.

Clang doesn't warn about my example above, despite having the same "wrong"
result.