Is the sizeof(enum) == sizeof(int), always?

by

It is compiler dependent and may differ between enums. The following are the semantics

enum X { A, B };

// A has type int
assert(sizeof(A) == sizeof(int));

// some integer type. Maybe even int. This is
// implementation defined. 
assert(sizeof(enum X) == sizeof(some_integer_type));

Note that “some integer type” in C99 may also include extended integer types (which the implementation, however, has to document, if it provides them). The type of the enumeration is some type that can store the value of any enumerator (A and B in this case).

I don’t think there are any penalties in using enumerations. Enumerators are integral constant expressions too (so you may use it to initialize static or file scope variables, for example), and i prefer them to macros whenever possible.

Enumerators don’t need any runtime memory. Only when you create a variable of the enumeration type, you may use runtime memory. Just think of enumerators as compile time constants.

I would just use a type that can store the enumerator values (i should know the rough range of values before-hand), cast to it, and send it over the network. Preferably the type should be some fixed-width one, like int32_t, so it doesn’t come to conflicts when different machines are involved. Or i would print the number, and scan it on the other side, which gets rid of some of these problems.

Response to Edit

Well, the compiler is not required to use any size. An easy thing to see is that the sign of the values matter – unsigned types can have significant performance boost in some calculations. The following is the behavior of GCC 4.4.0 on my box

int main(void) {
  enum X { A = 0 };
  enum X a; // X compatible with "unsigned int"
  unsigned int *p = &a;
}

But if you assign a -1, then GCC choses to use int as the type that X is compatible with

int main(void) {
  enum X { A = -1 };
  enum X a; // X compatible with "int"
  int *p = &a;
}

Using the option --short-enums of GCC, that makes it use the smallest type still fitting all the values.

int main() {
  enum X { A = 0 };
  enum X a; // X compatible with "unsigned char"
  unsigned char *p = &a;
}

In recent versions of GCC, the compiler flag has changed to -fshort-enums. On some targets, the default type is unsigned int. You can check the answer here.

More Related Contents:

  1. Easy way to use variables of enum types as string in C?
  2. Shall I prefer constants over defines?
  3. The need for parentheses in macros in C [duplicate]
  4. #define macro for debug printing in C?
  5. What is the difference between char * const and const char *?
  6. #pragma pack effect
  7. Real-world use of X-Macros
  8. MIN and MAX in C
  9. How do I check OS with a preprocessor directive?
  10. Stringification of a macro value
  11. What is the meaning of lines starting with a hash sign and number like ‘# 1 “a.c”‘ in the gcc preprocessor output?
  12. Macro vs Function in C
  13. Why can’t I convert ‘char**’ to a ‘const char* const*’ in C?
  14. Understanding container_of macro in the Linux kernel
  15. Why can I change a local const variable through pointer casts but not a global one in C?
  16. What does ## mean for the C(C++) preprocessor?
  17. Finding out what the GCC include path is [duplicate]
  18. Type of #define variables
  19. C preprocessor: expand macro in a #warning
  20. C circular dependency
  21. constness and pointers to pointers
  22. How is this const being used?
  23. hexadecimal floating constant in C
  24. Convert objective-c typedef to its string equivalent
  25. Pseudo-generics in C
  26. What is the possible use for “#define for if (false) {} else for”?
  27. Print text instead of value from C enum
  28. Is it Undefined Behaviour to cast away the constness of a function parameter?
  29. Detecting mismatched array enum initializers
  30. Macros to create strings in C

Leave a Comment