Why bit endianness is an issue in bitfields?

by

By the C standard, the compiler is free to store the bit field pretty much in any random way it wants. You can never make any assumptions of where the bits are allocated. Here are just a few bit-field related things that are not specified by the C standard:

Unspecified behavior

  • The alignment of the addressable storage unit allocated to hold a bit-field (6.7.2.1).

Implementation-defined behavior

  • Whether a bit-field can straddle a storage-unit boundary (6.7.2.1).
  • The order of allocation of bit-fields within a unit (6.7.2.1).

Big/little endian is of course also implementation-defined. This means that your struct could be allocated in the following ways (assuming 16 bit ints):

PADDING : 8
f1 : 1
f2 : 3
f3 : 4

or

PADDING : 8
f3 : 4
f2 : 3
f1 : 1

or

f1 : 1
f2 : 3
f3 : 4
PADDING : 8

or

f3 : 4
f2 : 3
f1 : 1
PADDING : 8

Which one applies? Take a guess, or read in-depth backend documentation of your compiler. Add the complexity of 32-bit integers, in big- or little endian, to this. Then add the fact that the compiler is allowed to add any number of padding bytes anywhere inside your bit field, because it is treated as a struct (it can’t add padding at the very beginning of the struct, but everywhere else).

And then I haven’t even mentioned what happens if you use plain “int” as bit-field type = implementation-defined behavior, or if you use any other type than (unsigned) int = implementation-defined behavior.

So to answer the question, there is no such thing as portable bit-field code, because the C standard is extremely vague with how bit fields should be implemented. The only thing bit-fields can be trusted with is to be chunks of boolean values, where the programmer isn’t concerned of the location of the bits in memory.

The only portable solution is to use the bit-wise operators instead of bit fields. The generated machine code will be exactly the same, but deterministic. Bit-wise operators are 100% portable on any C compiler for any system.

More Related Contents:

  1. What’s the best way to check if a file exists in C?
  2. How to measure time in milliseconds using ANSI C?
  3. How can one grab a stack trace in C?
  4. Why does glibc’s strlen need to be so complicated to run quickly?
  5. How should I print types like off_t and size_t?
  6. Is char *envp[] as a third argument to main() portable
  7. What belongs in an educational tool to demonstrate the unwarranted assumptions people make in C/C++?
  8. How do you get a directory listing in C?
  9. Any guaranteed minimum sizes for types in C?
  10. How is the size of a struct with Bit Fields determined/measured?
  11. How to use printf to display off_t, nlink_t, size_t and other special types?
  12. How does a C-style struct with a bitfield get represented in a Rust #[repr(C)] struct?
  13. How are 3D arrays stored in C?
  14. Cross Platform C library for GUI Apps? [closed]
  15. What’s the difference between “int” and “int_fast16_t”?
  16. Questions about C bitfields
  17. Signed bit field represetation
  18. Order of fields when using a bit field in C
  19. Does “volatile” guarantee anything at all in portable C code for multi-core systems?
  20. which is faster assigning a number to the variable or changing the value of that variable either by adding or subtracting some number?
  21. Storing value of unsigned int variable in char array in C [closed]
  22. Simple C scanf does not work? [duplicate]
  23. Need of Pointer to pointer
  24. Bitfield manipulation in C
  25. What happens when a variable goes out of scope?
  26. Where to find stdio.h functions implementations?
  27. Delete a Line from a file in C Language
  28. Store data in array from input [duplicate]
  29. Get index of substring
  30. Any benefit in using WEXITSTATUS macro in C over division by 256 on exit() status?

Leave a Comment