Thread: Bitfields, Bit/Little Endian

Originally Posted by matsp

Yes, it matters, because the compiler will still order bytes in the "little" or "big" endian way.

In a big endian machine, you expect the high bits to come first. Yes, the most significant BYTE is still the most significant BYTE, and bits within it are still in a determined order, but if you look at the bits, they are:
76543210
bbbbaaaa
whilst a little endian
01234567
aaaabbbb

Of course, if you have an unsigned char that you "and with 0x0F" or "and with 0xF0", both architectures will still work the same.

--
Mats

Yes sure, but within that one:

Code:

struct xy {
unsigned int a:4;
unsigned int b:4;
};

we just have one byte, so no ordering. That's actually what I meant. I read one byte from the package received over the network, and put it in those two "nibble-sized" bitfields,...no need for byte ordering there I think...

Rafael

I finally found something written down in a book online that confirms what we discussed here, if anyone want to read it:

C gives no guarantee of the ordering of fields within machine words, so if you do use them for the latter reason, you program will not only be non-portable, it will be compiler-dependent too. The Standard says that fields are packed into ‘storage units’, which are typically machine words. The packing order, and whether or not a bitfield may cross a storage unit boundary, are implementation defined.

Rafael