struct packing also isn't guaranteed by the C standard, everything around that is implementation defined, as it is with bitfield packing. __attribute__((packed)) is however implemented in any sensible C compiler implementation, and things around structure layout and memory layout of data types are specified in the compiler's manual. C would be useless without those implementation-specified guarantees, because most of the appeal of C for low-level-programming comes from the ease of deserialisation through something like

char * input = receive_data();

struct deserialized * decoded = (struct deserialized *)input; // zero cost deserialization

Of course this can only work if an implementation tells you exactly what the memory layout of 'struct deserialized' and all the data types in it are.

Btw, ordering is somewhat more defined than packing, in that the usual forward/reverse/little/big-endian shenanigans are OK. But relative ordering of each field is always preserved by the C standard.

The C standard doesn't guarantee much of anything. Windows and its drivers are using bitfields anyway because they trust MSVC to do the right thing.

Doesn't Linux make similar demands of the compiler, just not for bitfields? And I seem to recall Linus having some choice words for the C Standard's tendency over the years to expand the domain of undefined behavior. I don't think the Linux devs have much patience for C thinking it can weasel out of doing what it's told due to some small print in the Standard.