On 30/07/2026 05:33, Lawrence D?Oliveiro wrote:
The whole bitfield concept seems like something that C implementations
have never taken seriously. That has made programmers wary of them --
which of course the C compiler writers have taken as an excuse to
continue with their neglect.
Just saw a couple of commits come through in the libdvdread project
which reinforce this. It looks like somebody is wanting the code to
compile with something other than GCC now. Unfortunately, the
?MS-compatible compilers? they talk about don?t seem to be as smart
about packing bitfields.
Many of the details of bit-fields are implementation-specific. And
sometimes even within one compiler, they change (a very long time ago,
MS changed the order of bit-field allocations between two compiler
versions).
They work well if your code does not need to be very portable, or if the
exact layout doesn't matter (such as for internal data structures that
only exist during the runtime of the program). If you need them to work across different compilers or different processor architectures, you
need to be very careful. Static asserts on the size of your structs,
and perhaps some asserts at program startup can be a good idea. Or
change to using shifts and masks - that can be uglier in the code, but
the programmer has full manual control.
I don't think there is any neglect from compiler writers here, however.
IME they are good at making sure their tools follow the target's ABI.
But some systems - such as Windows - have much more limited ABI
information. When a target has no specified ABI for bit-fields,
compilers make different choices. Put the blame where it should go -
it's not the programmers' fault, but neither is it the compiler writers'.
--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)