From Newsgroup: comp.lang.c

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <86h5mv8umk.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

One might also define data structures for control and status
registers using bitfield structs.

Yeah. This kind of application (among others) I consider one of
the motivating forces behind bitfields.

[Some whitespace trimming done in the excerpt below.]

e.g. for the SATA UAHC_GLB_OOBR register:

union UAHC_GBL_OOBR {
uint32_t u;
struct UAHC_GBL_OOBR_s {
#if __BYTE_ORDER == __BIG_ENDIAN
uint32_t we : 1; /**< R/W/H - Write enable. */
uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
#else
uint32_t cimax : 8;
uint32_t cimin : 8;
uint32_t cwmax : 8;
uint32_t cwmin : 7;
uint32_t we : 1;
#endif
} s;
};

To me it seems kind of goofy to use uint32_t for the bitfields type.
I would just use unsigned, which is just as sure to work as intended,
isn't it?

No. There are issues of alignment and padding one must consider
when using bitfields to model hardware registers, particularly
if (say) a device driver is meant to be shared across ISAs.

Using the exact width types really does make a difference; it's
IB what those properties are, though we're usually at the mercy
of the target platform's ABI anyway at that point.

The motivation for my query was not to ask an abstract theoretical
question but a specific and pragmatic one.
--- Synchronet 3.22a-Linux NewsLink 1.2