Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Microcontroller software stacks (was Re: this girl calls c ugly)
Date: Fri, 14 Aug 2026 13:23:11 -0700
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <861pc078pc.fsf@linuxsc.com>
References: <10v7b32$2u85v$1@dont-email.me> <10vmh2e$b44$1@reader1.panix.com> <fkCTR.17300$_BG8.7520@fx24.iad> <86h5mv8umk.fsf@linuxsc.com> <111b3ni$s5m$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Fri, 14 Aug 2026 20:23:12 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="2956047"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18b4RSLaH9H8DAnjhwql6uUnj1KaYZXEyw="; posting-host="34d543ba31754db8d869ebd4dc5daf69"
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:mMvTysMMXUowy8r84Bd735aq4rY= sha1:7wGy7wgKiO9kckRNme7hpq1TPBc= sha256:o9cU6xenV+jLff1fjpSSGLd9USLaIk69d8t89QbFjNM= sha1:NZ/XiU+0g1oU/NqnkycH7J3jtbc= sha256:TGeNnE1Vd3kZRPRMfjrhU4gnq7ItAT3xA4hsGeyyN30=
Xref: csiph.com comp.lang.c:401177

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.