3 ms·

Yes, first you have to swab, if you have to swab.

monocasa 2y ago
Swab doesn't help in this case. It's the ordering of the bit fields within a word. So like is struct test_struct { uint8_t a: 1; uint8_t b: 1; uint8_t x: 6; }; xxxxxxba or abxxxxxx? ie. to get to member 'a' do you mask 0x80 or 0x01?
- adrian_b 2y ago
  You should never do yourself masking or shifting. The compiler will always choose the appropriate machine instructions for the target ISA, which may have dedicated bit field extraction and bit field insertion instructions that are more efficient than the equivalent sequences of masking, shifting and merging instructions. Moreover, the compiler will handle any endianness correctly. In networking applications, where structures created on a computer may need to be used on another computer, the communication protocol will always serialize any data to a known format and the protocol implementation will provide conversion procedures to and from the native data formats. So the only place where one may be concerned about endianness is when writing a conversion function between a native data format and some format specified for communication or storage. In this case it is known precisely which are the endiannesses for the native CPU and for the standard storage or communication data format. For the standard format, its specification, e.g. an Internet RFC, will specify exactly the layout of the bits. For the native data format, you do not need to know the order of the bit fields. You just assign data to the structure members and or you assign the structure members to other variables and the compiler will take care of the layout.
  - monocasa 2y ago
    Y'all are missing the point. The difference between xxxxxxba and abxxxxxx is implementation defined, and changes with different architectures even with the same compiler. That means in the "an Internet RFC [...] exactly [specified] the bits" case, you actually need multiple implementations for different architectures to be portable. So waht you end up having is struct test_struct { #if ARCH_BIT_ENDIANNESS == BIG uint8_t a: 1; uint8_t b: 1; uint8_t x: 6; #else uint8_t x: 6; uint8_t b: 1; uint8_t a: 1; #endif }; for every struct for portable code that has to use bitfields with an externally defined bit pattern. And it's not that goofy of archs that do it the opposite way of x86. PowerPC is a good example.

Swab doesn't help in this case. It's the ordering of the bit fields within a word. So like is struct test_struct { uint8_t a: 1; uint8_t b: 1; uint8_t x: 6; }; xxxxxxba or abxxxxxx? ie. to get to member 'a' do you mask 0x80 or 0x01?

adrian_b 2y ago
You should never do yourself masking or shifting. The compiler will always choose the appropriate machine instructions for the target ISA, which may have dedicated bit field extraction and bit field insertion instructions that are more efficient than the equivalent sequences of masking, shifting and merging instructions. Moreover, the compiler will handle any endianness correctly. In networking applications, where structures created on a computer may need to be used on another computer, the communication protocol will always serialize any data to a known format and the protocol implementation will provide conversion procedures to and from the native data formats. So the only place where one may be concerned about endianness is when writing a conversion function between a native data format and some format specified for communication or storage. In this case it is known precisely which are the endiannesses for the native CPU and for the standard storage or communication data format. For the standard format, its specification, e.g. an Internet RFC, will specify exactly the layout of the bits. For the native data format, you do not need to know the order of the bit fields. You just assign data to the structure members and or you assign the structure members to other variables and the compiler will take care of the layout.
- monocasa 2y ago
  Y'all are missing the point. The difference between xxxxxxba and abxxxxxx is implementation defined, and changes with different architectures even with the same compiler. That means in the "an Internet RFC [...] exactly [specified] the bits" case, you actually need multiple implementations for different architectures to be portable. So waht you end up having is struct test_struct { #if ARCH_BIT_ENDIANNESS == BIG uint8_t a: 1; uint8_t b: 1; uint8_t x: 6; #else uint8_t x: 6; uint8_t b: 1; uint8_t a: 1; #endif }; for every struct for portable code that has to use bitfields with an externally defined bit pattern. And it's not that goofy of archs that do it the opposite way of x86. PowerPC is a good example.