Bitfields, Bit/Little Endian

Quote:

---

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

Quote:

---

Originally Posted by brewbuck

gcc promises all sorts of things above and beyond the standard. Long ago it was decided that to compile the Linux kernel, you needed gcc. So kernel and system developers are free to take advantage of any gcc property they feel like.

Obviously there is no need for system-level code to conform to any standard so long as it works correctly.

Conversely, the gcc people work to try to maintain backward compatibility. But NONE of this is "standard."

---

And it is not unusual that OS vendors [1] do these things - only where the OS vendor supports multiple compile environment does it become important to NOT rely on what one or another compiler does - the Windows headers are full of pragmas that only work in MS C/C++ compilers for example. Linux and many other open source products make use of gcc-isms that make it impossible [or require effort at least] to compile the product with any other compiler.

[1] "vendors" here is a loose term, rather than "commercial entities".

--
Mats

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

Quote:

---

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