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: Storage needed when there are bit-field members
Date: Sun, 23 Aug 2026 07:53:23 -0700
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <864igkzy58.fsf@linuxsc.com>
References: <10v7b32$2u85v$1@dont-email.me> <10vkk65$l8v$1@reader1.panix.com> <10vlvie$2ne3j$2@dont-email.me> <10vmh2e$b44$1@reader1.panix.com> <fkCTR.17300$_BG8.7520@fx24.iad> <86h5mv8umk.fsf@linuxsc.com> <111amdq$1at39$1@dont-email.me> <111b35d$1duuq$1@kst.eternal-september.org> <86v7b27h20.fsf_-_@linuxsc.com> <111sgeq$3vq40$1@kst.eternal-september.org> <111soae$1eq8$1@kst.eternal-september.org> <86o6f45pu7.fsf@linuxsc.com> <5GMfS.13614$EDc8.5150@fx24.iad> <86cxvj3rq1.fsf@linuxsc.com> <jzkgS.4883$4QJ.2251@fx21.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 23 Aug 2026 14:53:25 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="2117014"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/on+vNFmEBHmrU/r58wnf9JKu2jTrc3bQ="; posting-host="f66050aa85370b7b068c3e444f0a8412"
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:8fZv5yltVEObwc8oBH8+I/6S2A8= sha1:HEv7zOXXV99bIwTiDX1Z+4QvpjA= sha256:3FjEVrsFneiZCSkm4DbFDMY5JGUmvghV4oig3DvBkmc= sha1:9BFkzr3fmJh+1Ww2PvOm/DEd7Bo= sha256:bjLrQOZaTxf/sCN/J9tiGSYMFIcmMqz5s60fMhR/n8k=
Xref: csiph.com comp.lang.c:401436

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>
>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>
>>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>
>>>>> Here's a test program:
>>>>>
>>>>> #include <stdio.h>
>>>>> #include <stddef.h>
>>>>> int main(void) {
>>>>>     struct s1 { unsigned char bf:1;      unsigned char c; };
>>>>>     struct s2 { unsigned short bf:1;     unsigned char c; };
>>>>>     struct s3 { unsigned int bf:1;       unsigned char c; };
>>>>>     struct s4 { unsigned long bf:1;      unsigned char c; };
>>>>>     struct s5 { unsigned long long bf:1; unsigned char c; };
>>>
>>> FWIW, adding GCC's __attribute__((packed)) to each of those, we
>>> see:
>>>
>>>> type               size offset struct-size
>>>> unsigned char      1    1      2
>>>> unsigned short     2    1      2
>>>> unsigned int       4    1      4
>>>> unsigned long      8    1      8
>>>> unsigned long long 8    1      8
>>>
>>> type               size offset struct-size
>>> unsigned char      1    1      2
>>> unsigned short     2    1      2
>>> unsigned int       4    1      2
>>> unsigned long      8    1      2
>>> unsigned long long 8    1      2
>>>
>>> Which doesn't seem to violate the ABI rules you quoted.
>>
>> That's good to know I guess, although I'm not sure what it
>> tells me.  My impression is that using attribute__((packed))
>> produces code that may be less portable than not using it.
>> Generally I try to write code that avoids compiler-specific
>> constructs whenever feasible.
>
> I generally only use the packed attribute when creating
> a C struct to match a hardware register, data structure or
> data packet.

I would use the packed attribute if it were necessary to conform
to some externally imposed layout, such as a hardware register or
network packet.  I don't know of any cases were it is necessary.
Maybe the data formats you need to match are more exotic than
ones I am used to.  Can you give an example of a format where the
format cannot be matched using only language features available
in standard C?