3 ms·
Until I read this article that's what I thought C Bitfields _were_. I didn't realize the specification was so uselessly sloppy about alignment packing that a p
by mjevans 5y ago
Until I read this article that's what I thought C Bitfields _were_. I didn't realize the specification was so uselessly sloppy about alignment packing that a programmer couldn't reliably address specific bit field members with just a lowest bit first to highest bit field of exact widths. It's quite annoying that such is not what those are.
- scatters 5y agoIf the specification is lax, it's because the expected behavior is different across platforms. C (and C++) has to support platforms where bytes are more than 8 bits, where floats are non-IEEE, and (until recently) where signed integers are not 2's complement. If you want a specific behavior and don't care about portability all you have to do is read the ABI spec alongside the standard.
- ncmncm 5y agoYou have wholly missed the point of the warning. It does not matter what the spec says when the instructions fail to implement it, sometimes, on machines other than yours.
- froh 5y agoPlease add endianness (little, big and mixed) to the list, relevant to but field packing, while IEEE floats should not interfere with bit fields.
- Asooka 5y agoThe ABI for a specific platform will define how bit fields are arranged in memory, or at least you can always rely on GCC to not change behaviour. They work perfectly well for data in memory, at work we use them all the time for storing tiny integers or flags.
- ncmncm 5y agoThey work on the machines where you have tested them. The ABI defines what is supposed to happen, not what will happen. Gcc will get it right on very heavily used archs, and very heavily used archs will generally execute the instructions right. If your code only ever runs on the physical machines where you test, or only on very mainstream chip designs, then fine. You have been warned. Now it is on you.