bitfields concern

[cacollin]

It seems that we should move away from using bitfields if we are trying to have the code be platform independent. We (Land PEATE) found some arguments to support this when researching bitfield usage online:

"In general you should avoid bitfields and instead use explicit bit masking and shifting to access the 'sub-fields' in a field.

Here's one reason why bitfields should be avoided - they aren't very portable between compilers even for the same platform. from the C99 standard (there's similar wording in the C90 standard):

An implementation may allocate any addressable storage unit large
enough to hold a bitfield. If enough space remains, a bit-field that
immediately follows another bit-field in a structure shall be packed
into adjacent bits of the same unit. If insufficient space remains,
whether a bit-field that does not fit is put into the next unit or
overlaps adjacent units is implementation-defined. The order of
allocation of bit-fields within a unit (high-order to low-order or
low-order to high-order) is implementation-defined. The alignment of
the addressable storage unit is unspecified.

You cannot guarantee whether a bit field will 'span' a boundary or not and you can't specify whether a bitfield starts at the low-end of the int or the high end of the int (this is independent of whether the processor is big-endian or little-endian)."

[houchin]

I agree, and have seen the same discussions online. In addtion, when it does break, it will likely break in a way that isn't obvious and it could be hard to verify.

[cacollin]

Perhaps a regular DR should be written against the IDPS code on this? I've emailed Neal Baker to get feedback since he's managing a lot of the DRs.

[Alice.Isaacman]

By all means submit a DR. It should generate attention. This has always been a real pain!