Explore Sign in Sign up
Echo Reply
Computers, Science, Technology, Xen Virtualization, Hosting, Photography, The Internet, Geekdom And More

Gcc Easter Eggs – Shorter Enum Storage

Published on Nov. 9, 2009 at midnight by XC

This is the first in what will likely be a long series of posts regarding features in GCC that I find to be less than obvious. Technically, an easter egg (in a program) is some sort of functionality that accessed by undocumented and non-obvious means.

To the less than guru regarding GCC, a lot of switches seem to fall into that category, though it is one of the best documented compilers ever written. In fact, a lot of people that I know keep their own cheat sheet to document handy bits that they find for future reference. This new tag happens to be my list, hope you find it useful.

On to it – I saw an interesting answer to a question today regarding what storage type an enumerated list actually corresponds to on any given platform .. and what control (if any) one may have over it.
Typically, at least on Linux, an enum is going to boil down to a 16 bit integer. That really sucks if your list contains the values of 0, 1 and 2.

Not to worry, GCC’s -fshort-enums switch is there to help:

Allocate to an “enum” type only as many bytes as it needs for the declared range of possible values. Specifically, the “enum” type will be equivalent to the smallest integer type which has enough room.

Thanks to Michael Foukarakis for that little tidbit. This lets you cut the size of a typical enum in half (i.e. 8 bit storage) without having to revert to preprocessor abuse.

That’s really helpful, especially dealing with some kind of line protocol / device that gives 8 bit responses, so much easier to pass them around using an enumerated list.