Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Microcontroller software stacks Date: Sat, 15 Aug 2026 16:16:38 -0700 Organization: A noiseless patient Spider Lines: 65 Message-ID: <868q673rft.fsf@linuxsc.com> References: <10v7b32$2u85v$1@dont-email.me> <10vjsg2$259m3$3@dont-email.me> <10vkk65$l8v$1@reader1.panix.com> <10vlvie$2ne3j$2@dont-email.me> <10vmh2e$b44$1@reader1.panix.com> <86h5mv8umk.fsf@linuxsc.com> <865x1c7a63.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sat, 15 Aug 2026 23:16:39 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3954883"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bInr+2Z7iY7QvGajc1FK4xWo8KMzMWE8="; posting-host="f88cfb7384c39afe54609bf3101f3803" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:VLipKYbqgwHyz+evMK7C6PtIjVQ= sha1:IgUNM6jT9G48PBIZ5K4P2u4DMt4= sha256:atBTfIbClGUab/8A9DXy/IUmdDwyccRP2/u1Hl1EFiY= sha1:vxpK8NkGo1hKhrVUoAvxnPXYxdk= sha256:Lr/mJBq/5gm3dN07pkJ913fy69J4myKg4pB0RFaCn9s= Xref: csiph.com comp.lang.c:401224 scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch writes: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Tim Rentsch writes: >>> >>>> 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? >>> >>> The SATA hardware register is defined as a 32-bit register in the >>> SATA specification. Therefore we explicitly declare it as such. >> >> I understand the motivation for using uint32_t for the union member >> u. My question is only about the type used for the bitfields. Do >> you know of any platform, or even suspect that there might be a >> platform, where using 'unsigned' rather than 'uint32_t' for the type >> of the bitfields makes any difference at all? > > I haven't canvassed all the available platforms, and don't have > any desire so to do. In my opinion, using the same type for the > bitfield members as was used for the corresponding union > element is simply logical. If we declare the integer part > of the union as uint64_t, we use the same time for the > bitfields (and yes, we could have used unsigned long > (or unsigned long long on the micky OS) - uint64_t > is less typing. To me it seems more logical to use the smallest basic type that suffices for the width of the associated bit-field, assuming the compiler allows it, or 'unsigned' for compilers that don't provide those extensions.