Messages in this thread | | | Date | Thu, 9 Sep 2004 12:09:47 +1000 | From | Peter Chubb <> | Subject | Re: [PATCH] netpoll endian fixes |
| |
>>>>> "Duncan" == Duncan Sands <baldrick@free.fr> writes:
Duncan> Hi Matt, I agree that it should be 0x45 everywhere. After Duncan> thinking a bit I concluded that the
Duncan> #if defined(__LITTLE_ENDIAN_BITFIELD) Duncan> __u8 ihl:4, version:4; Duncan> #elif defined (__BIG_ENDIAN_BITFIELD) Duncan> __u8 version:4, ihl:4;
Duncan> in the definition of struct iphdr is to make sure that Duncan> compiler uses the first four bits of the byte to refer to Duncan> version, rather than the last four; and this only matters when Duncan> you are accessing the nibbles via the ihl or version structure Duncan> fields. Thus it makes sure that if you write 0x45 to the Duncan> byte, then version will return 4 and ihl will return 5. Duncan> Presumably the C standard specifies how bitfield expressions Duncan> should be laid out in the byte, and ihl:4, version:4; gives Duncan> opposite results on little-endian and big-endian machines...
Actually, the C standard
-- leaves unspecified whether bitfields start at the low or high address of the word they're in, and
-- states that the type of a bitfield may be ignored (except for signed/unsigned), and that the size of the object containing a bitfield is the same as the size of an int.
It's a GCC extension that allows __u8 ihl:4; to allocate only 8 bits and use four of them; GCC still assumes integer alignment for the whole bitfield block. Other compilers could allocate 32 bits.
-- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au The technical we do immediately, the political takes *forever* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |