Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #401347
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Storage needed when there are bit-field members |
| Date | 2026-08-20 11:00 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <1166fo6$3blln$1@dont-email.me> (permalink) |
| References | (9 earlier) <86v7b27h20.fsf_-_@linuxsc.com> <111sgeq$3vq40$1@kst.eternal-september.org> <111soae$1eq8$1@kst.eternal-september.org> <11650g9$19gjl$1@paganini.bofh.team> <1165ai6$314h2$2@kst.eternal-september.org> |
On 20/08/2026 00:26, Keith Thompson wrote: > antispam@fricas.org (Waldek Hebisch) writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: [...] >> Other post mentioned gcc "packed". gcc "packed" does not >> respect alignment rules, so in such cases 2 byte are enough >> regardless of type. > > gcc "packed" can also cause quiet crashes on some systems. It can > result in, for example, an int member being allocated at an odd address. > Passing the address of such a member to a function that assumes the > pointed-to object is correctly aligned can result in Bad Things > Happening. (On x86, as I understand it, misaligned accesses > are merely somewhat slower than aligned accesses.) > > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628> > <https://stackoverflow.com/q/8568432/827263> > <https://stackoverflow.com/a/8568441/827263> > gcc "packed" can cause problems only if you don't use the compiler correctly (or if there are bugs in the compiler, as happens occasionally. gcc's bugzilla seems to be having trouble, so I have not checked your bug link). As you say, "packed" means that struct fields can be misaligned. This has two potential problems. One is that if you take the address of a field, you then have a pointer whose value is invalid for dereferencing as that type - so dereferencing it is UB. (You can still convert it to a character pointer and dereference that.) A compiler could therefore assume that if you have "int * p;" and you dereference it, then "p" must be correctly aligned. AFAIUI gcc does not make such assumptions, precisely because misaligned pointers do turn up in some code (either from the use of "packed" or by other means), and it is not an optimisation that is likely to be useful in any but the most obscure niche cases. (And if you have code in that category, you can always use __builtin_assume_aligned() to give the compiler the additional information.) The real problem with misaligned data is that on some systems, accessing misaligned data is not supported by the hardware. Such hardware certainly exists. From the links you gave, it appears to apply to SPARCs. It certainly applies to some of the smaller and cheaper ARM Cortex-M cores (M0, M1, M23 - perhaps more). And even on bigger devices, there can particular instructions that require correct alignment, such as "move multiple registers" or "load/store double register". In the x86 world, I believe there are some SIMD load/store instructions that must use aligned addresses. For most processors, and most instructions, misaligned accesses work but are a little slower than aligned accesses. If a misaligned access is not supported, the effects vary by device. Some will trigger a hardware fault and a program crash. Some will have a hardware fault and then software emulation of the misaligned access - then it will "work", but be /massively/ slower. And for some you simply get the wrong access - your program silently does the wrong thing. (On the msp430, trying to access a 16-bit value at an odd address had - in my brief testing long ago - the effect of accessing the data at one bye lower address but with swapped endianness. This is not a documented effect, however, so not something to rely on.) gcc is smart enough to use smaller accesses when it knows it is necessary. Accessing a misaligned 32-bit field when targeting a Cortex-M4 will give normal load/store 32-bit instructions - when targeting an M23, it will generate multiple 8-bit or 16-bit load/stores. And if you take a pointer to a packed field, you get a warning. So I think you have to put a bit of effort into getting in trouble here - you have to use pointers and ignore warnings, or use inappropriate command-line switches or generate code targeting one processor and try to run it on a different processor.
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 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 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 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-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-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