[m3koval]

The bitfield example is misleading. Section 6.7.2.1/10 of the C99 standard says:

"The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined"

There is no guarantee on the order of the bits inside a bitfield. The compiler may also introduce padding, e.g. for alignment purposes. This makes bitfields unusable for unpacking binary data.

Unfortunately, you're stuck with shifting and masking to replicate the same effect.

[gdwatson]

Implementation-defined behavior is still defined, in this case probably by the platform ABI. It's simply not portable.

[Too]

I've had very nasty experiences with bitfields even though the order was well defined on that platform. It was an embedded system where someone got the idea to create bitfield access to a cpu register.

The problem was that some bits in that register would be cleared automatically each time, so even if you wrote 0 it would read back as 1 the next time. Some other bit would always trigger an action if you wrote to it regardless if you wrote the same value as it had before, this was called the send_bit and when you wrote 0 it sent some stuff onto the network cable. So code that looked perfectly fine like this:

    register.bitsa = 0x2;
    register.bitsb = 0x1;
    register.send_bit = 0.

Actually sent 3 packets instead of 1 because the compiler translated each write of a bitfield member to a write of the whole register, some other bits in bitsa could get corrupted by the bitsb-write since they didn't read back as they were written. I assume the cpu had a minimum addressable unit of 8 bits so the compiler had to translate each line into something like register = (register | setbits) & clearbits; which requires reading the previous value each time just to write a single bit, this is very easy to overlook when you just see the three lines of code being written in a neat sequence.

[restalis]

"sent 3 packets instead of 1 because the compiler translated each write of a bitfield member to a write of the whole register"

So the problem was the fact that the language gives the impression of having more control than what the hardware is actually offering. In this case bit access must have been better left to platform-dependent libraries (when it would present itself as something more than what masks usage can do).

[vardump]

> It was an embedded system where someone got the idea to create bitfield access to a cpu register.

Most PCI/PCIe devices have memory mapped registers that behave similarly. Like DMA registers... Although it's a bit bad idea to trigger send on writing 0 bit to the corresponding bit in the register. But hardware memory mapped registers are weird and these things are common. Like writing 1-bit to clear.

[comex]

Yeah, combining bitfields with volatile is an extremely bad idea. I've heard, and give some credence to, opinions using volatile at all in normal code, rather than hiding it in a helper or something, is a bad idea, given that that allows reading and writing registers to look the same as normal memory accesses, despite it having extremely different consequences.

[buserror]

That's one of the few nag I have about C; this syntax is fantastic, and theoretically allow the compiler quite a lot of freedom to optimize access to the bitfield, and the fact that it was never standardized means you just can't use it if you want portable code.