Bitfields, Bit/Little Endian

This is a discussion on Bitfields, Bit/Little Endian within the C Programming forums, part of the General Programming Boards category; Originally Posted by matsp Yes, it matters, because the compiler will still order bytes in the "little" or "big" endian ...

  1. #16
    Registered User
    Join Date
    Oct 2007
    Posts
    22
    Quote Originally Posted by matsp View Post
    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

  2. #17
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by brewbuck View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #18
    Registered User
    Join Date
    Oct 2007
    Posts
    22
    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

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Bitfields, Bit/Little Endian
    By azerej in forum C Programming
    Replies: 0
    Last Post: 05-26-2008, 02:01 AM
  2. Big Endian & Little Endian
    By swaugh in forum C Programming
    Replies: 18
    Last Post: 06-06-2007, 11:25 PM
  3. Big Endian Little Endian Complex- Converting Characters
    By bd02eagle in forum C Programming
    Replies: 3
    Last Post: 07-11-2006, 01:01 AM
  4. Big and little endian
    By Cactus_Hugger in forum C Programming
    Replies: 4
    Last Post: 10-12-2005, 07:07 PM
  5. Replies: 10
    Last Post: 06-26-2005, 11:27 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21