[riot-devel] enums vs. macros

Joakim Gebart joakim.gebart at eistec.se
Wed May 13 09:49:30 CEST 2015


gcc's -fshort-enums might do what you describe:

https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html:

-fshort-enums Allocate to an enum type only as many bytes as it needs
for the declared range of possible values. Specifically, the enum type
is equivalent to the smallest integer type that has enough room.

Warning: the -fshort-enums switch causes GCC to generate code that is
not binary compatible with code generated without that switch. Use it
to conform to a non-default application binary interface.

/Joakim

On Wed, May 13, 2015 at 8:12 AM, Oleg Hahm <oliver.hahm at inria.fr> wrote:
> Dear replying IoTlers,
>
> some time ago I had a discussion with Martine on GitHub about the usage of
> enums for flags [1]. Martine convinced me that seems to be wise to prefer
> macros over enums here, to avoid alignment issues. However, it feels somehow
> wrong not to use enums for this purpose (it's easier for the developer *and*
> the compiler if a valid data type is chosen). Does anyone know a trick around
> the issues that Martine mentioned:
>> Because flags have a width in memory that is in most cases smaller than
>> sizeof(enum) (most bit fields I know of are 16 bits max, on most of our
>> newer platforms, sizeof(enum) is however 32 bits). This results in every
>> assignment needed to be cast to either uint8_t or uint16_t. With macros you
>> don't need to cast since they are typeless.
>>
>> Making the enum packed makes it's width unpredictable in terms of alignment
>> issues, when used in struct (which is not the case here, I know).
>
> Cheers,
> Oleg
>
> [1] https://github.com/RIOT-OS/RIOT/pull/2614#discussion_r28941692
> --
> panic ("No CPUs found.  System halted.\n");
>         linux-2.4.3/arch/parisc/kernel/setup.c
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>


More information about the devel mailing list