warning: comparison of integer expressions of different signedness: ‘int’ and ‘en’ {aka ‘enum ’}

Question

Having this code:

#include <stdio.h>
#include <stdlib.h>

int main (void) {

   typedef enum {bar,baz,last} en;
   en foo = baz;
   for(int i =bar; i<=last ; i++)
      if(i==foo){
         printf("%i\n",i);
      }

   return 0;
}

Why does compiler cares about signedness of enum members? They should be represented from 0 up (e.g bar=0,baz=1,...) and because they are starting from 0 up, they could never be negative, and therefor no reason to case about signedness (unless I assign bar=-1, but do not know if that is possible). So why the error?

Answer 1

The compiler cares about signedness because all integer types, including enum types, are either signed or unsigned. For an enum, the exact underlying integer type is definfed by the specific implementation. Section 6.7.2.2p4 of the C standard states:

Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined, but shall be capable of
representing the values of all the members of the
enumeration. The enumerated type is incomplete until immediately after the } that terminates the list of enumerator declarations, and complete thereafter.

For gcc in particular, it is defined as follows:

• The integer type compatible with each enumerated type (C90 6.5.2.2, C99 and C11 6.7.2.2).

Normally, the type is unsigned int if there are no negative values in the enumeration, otherwise int. If -fshort-enums is specified, then if there are negative values it is the first of signed char, short and int that can represent all the values, otherwise it is the first of unsigned char, unsigned short and unsigned int that can represent all the values.

On some targets, -fshort-enums is the default; this is determined by the ABI.

Because you didn't explicitly set values for your enum, the values start at 0 and go up from there. So assuming you are using gcc, it chooses unsigned int as the underlying type.

Answer 2

Why does compiler cares about signedness of enum members?

It is not the signedness of an enum per se that the compiler cares about here but the signedness of the things you are comparing.

When you have x == y, and x is a signed integer and y is an unsigned integer, they are not compared directly. The rules of C say that one must be converted to the type of the other. If the signed integer type is narrower (technically, has lesser conversion rank) than the unsigned type, it is converted to the unsigned type.

This conversion can change the value of the number, and that can produce a result different from what you desired. For example, -3 < 4u will produce false (0), because converting −3 to unsigned produces a large value (4,294,967,293 in common C implementations). Or -3 == 4294967293u would produce true (1).

So the compiler is warning you that, because of the difference in signedness, the comparison might not behave as you desire.

In this case, the compiler has based its warnings solely on the types of the operands. Looking at the code, we can see that neither of the operands will have a negative value, so the specific values you are comparing will not be affected by this problem. But making that distinction is apparently beyond the capabilities of the compiler you are using.

Answer 3

You could as well have done typedef enum {bar=-1,baz,last} en; and potentially gotten a different enumerated type.

It's important to know that C is dysfunctional and inconsistent when it comes to the type of enums. The enumeration constants (bar etc) are guaranteed to always be type int, but the enumerated type (en) may have any implementation-defined integer type that fits all the constants in the list. It may be signed or unsigned. From the C standard 6.7.2.2:

Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined, but shall be capable of representing the values of all the members of the enumeration.

You can have different types for different enums in the same program. The rationale was perhaps that they wanted to save space. But this comes at the cost of portability and non-deterministic typing.

The compiler probably gives a general warning here without checking what internal type en actually equals. You can check yourself with a C11 macro:

#define type_print(x) _Generic((x),                                  \
                               int:          puts("int"),            \
                               unsigned int: puts("unsigned int"),   \
                               default:      puts("something else"))

type_print(foo);

This gives me unsigned int on gcc x86, and so i==foo triggers a signed vs unsigned conversion warning. Best way to fix the problem is to do for(en i=bar; ... instead.

Answer 4

Although the problem is small, is has a lot going on

typedef enum {bar,baz,last} en;
en foo = baz;
for(int i =bar; i<=last ; i++)
  if(i==foo){

As well answered by @lundin:
* The en constants are int
* Objects of type en are char, a signed integer type, or an unsigned integer type.

Code has 2 compare function with int and en.

i<=last
i==foo

Yet As I understand, only the 2nd one warns about "comparison of integer expressions of different signedness: ‘int’ and ‘en’".

In the first case, i<=last: last is a en constant, so that is simple int <= int --> no warning.

But surprisingly had code been unsigned i, i<=last does not warn even it is now a "integer expressions of different signedness".

Changing the last is still a "integer expressions of different signedness" yet no warning.

// i==foo
(i&1)==foo

Conclusion "integer expressions of different signedness" warning happens when 2 conditions are met:

• Types are of different sign (no rocket science on this one).
• The compiler concludes the range of possible values of the signed side and the range of the values of the unsigned are not both in the positive signed range - or something like that.

Although our human analysis of for(int i =bar; i<=last ; i++) if(i==foo){ printf("%i\n",i); } sees no compare problem here, the compiler missed it.