Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #401438
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Storage needed when there are bit-field members |
| Date | 2026-08-23 17:33 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <116f3rt$2155t$1@dont-email.me> (permalink) |
| References | (11 earlier) <86o6f45pu7.fsf@linuxsc.com> <5GMfS.13614$EDc8.5150@fx24.iad> <86cxvj3rq1.fsf@linuxsc.com> <jzkgS.4883$4QJ.2251@fx21.iad> <864igkzy58.fsf@linuxsc.com> |
On 23/08/2026 16:53, Tim Rentsch wrote:
> 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?
Programmers do not - IME - use "packed" structs because it is the only
way to deal with externally imposed layout. They use them because they
are sometimes the simplest, clearest and most efficient methods. Since
you can always access data using pointers to unsigned char, it is never
the /only/ way to do things.
The code I am currently working on deals with a specialised network
interface chipset for power-line communication. The packets sent back
and forth between the chipset and the microcontroller I am programming
have different formats for the different messages types - some 30
different types. Each format contains mixes of 8-bit, 16-bit, 32-bit
and sometimes bigger fields, with no padding and no consideration for
alignment.
Now, there is no doubt that this could all be handled by receiving the
incoming telegram into an array of unsigned char, pulling out the bytes
individually, building up the fields with shifts and ors, then storing
the results into a new struct that has the same fields with native
padding and alignment. Alternatively, I could have types defined like
"typedef struct { unsigned char v[4]; } packed_32_t;", and so on, and
use these as fields of a struct that directly matched the format of the
hardware telegram.
But it is /far/ simpler and clearer to use a packed struct. It gives
the most efficient resulting code, avoids unnecessary extra copies
(saving clock cycles and ram space), is easy to check with the
documentation, and easy to maintain.
I think you would be very hard pushed to find a case where packed
structs are the /only/ solution, but it's not hard to find cases where
many programmers would consider them the /best/ solution. (Usually a
certain degree of non-portability is fine in such systems.)
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:13 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 08:58 +0200
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 03:35 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:50 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 12:59 +0200
Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:42 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:06 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:20 -0700
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:56 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 22:30 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:10 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 15:20 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-23 07:53 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-23 17:33 +0200
Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:34 +0000
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:26 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 11:00 +0200
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 03:30 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 13:58 +0200
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 13:37 -0700
Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-21 14:31 +0300
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-21 13:41 +0200
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 15:41 +0000
Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-21 14:58 +0300
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-20 14:50 +0000
Re: Storage needed when there are bit-field members "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:31 -0700
Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-20 19:55 +0000
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-21 08:57 +0200
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 14:59 +0000
Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-20 22:15 +0300
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:19 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:45 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:23 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:23 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:32 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:04 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 13:02 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:51 -0700
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 05:02 +0800
Re: Microcontroller software stacks bart <bc@freeuk.com> - 2026-08-15 01:18 +0100
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-16 13:52 +0800
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:06 -0700
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 21:42 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 22:13 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-15 19:39 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 23:22 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 14:38 +0000
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-16 16:11 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-23 07:56 -0700
Re: Microcontroller software stacks David Brown <david.brown@hesbynett.no> - 2026-08-23 17:37 +0200
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-23 16:09 +0000
Re: Microcontroller software stacks "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-23 19:42 -0700
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-23 16:08 +0000
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:16 -0700
Re: Microcontroller software stacks cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:34 +0000
Re: Microcontroller software stacks antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:57 +0000
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-23 10:54 -0700
Re: Microcontroller software stacks antispam@fricas.org (Waldek Hebisch) - 2026-08-23 21:22 +0000
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:51 +0800
csiph-web