A silly question/suggestion:
Wouldn't it make sense to use sized integer types in the struct, but a separate
enum to define the values? IIRC, enum's in C are simply named integer
constants. C is also very permitting in storing values into smaller integer
types. For C++, of course, the situation may not be that easy.
typedef struct {
uint16_t flags;
} foo_t;
typedef enum {
FOO_FLAG_ONE = 0x01,
FOO_FLAG_TWO = 0x02,
FOO_FLAG_THREE = 0x04,
} foo_flags_t;
--Pekka
> On 2015–05–13, at 9:12 , Oleg Hahm <oliver.h...@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@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
