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: Sun, 23 Aug 2026 10:54:11 -0700 Organization: A noiseless patient Spider Lines: 52 Message-ID: <86qzjoyb7g.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> <868q673rft.fsf@linuxsc.com> <11651rc$19gjl$2@paganini.bofh.team> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 23 Aug 2026 17:54:15 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2239686"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+zNB9hJiIDy3sFAeii3YW3w2i8CYPk3ZI="; posting-host="f66050aa85370b7b068c3e444f0a8412" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:nEMqHVQaMCLIEg8rBJ10BbI7QOg= sha1:ReErWFLATid59oB1k1Cvo/SERAw= sha256:1EqOLgXeRwauIanxio1KFnt4tVxn7u5PMNiFm+y5LhI= sha1:jzx1+G8jE794rQ6clbCkOMBzDGY= sha256:6UJULKa+WZ93nSlrd28RD1AtiH2gkcmf/vmlnMTVwyk= Xref: csiph.com comp.lang.c:401443 antispam@fricas.org (Waldek Hebisch) writes: > Tim Rentsch wrote: >>> [on deciding which type to use for a bit-field member] >> 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. > > Conider the following two structs: > > typedef struct {char a:5; char b:5; char c:5;} bf1; > > typedef struct {short a:5; short b:5; short c:5;} bf2; > > gcc allocates 3 bytes to first one and 2 bytes for the second one. That's interesting; thank you for the research. I wouldn't expect code to use char for a bit-field type but presumably unsigned char or signed char would give the same result. > Bitfields are frequently used to converve memory and the second > one is better in this aspect. So it is hard the avoid notion > of storage unit and using type to control size of storage unit. In the early days of C conserving space may have been a common consideration. These days I expect it hardly ever is, except perhaps in the case of lots of _Bool bit-fields. Furthermore there are advantages to using a type where the members occupy separate bytes rather than being packed into a single 16-bit object. The generated code may be better. Also using a single byte for each member reduces the change of undefined behavior when accessing these bit-fields. > Of course, if you can not count on compiler behaving in specific > way, abd you can not tolerate different behaviour, then it is better > to use access if given needed size and masks and shifts to access > the bits. I hope it goes without saying that whenever it is necessary to conform to an externally imposed layout, and bit-fields are used to effect that, that the layout produced by the compiler(s) should be checked against the external specification, and that whatever type-selection heuristics are used should be adjusted to ensure the needed conformance does in fact occur. Using masks and shifts -- and probably macros -- can provide a more reliable alternative in some cases; but that approach also carries its own set of downsides, which need to be weighed against other approaches.