-
-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bitfield order defaults to MostToLeastSignificant in big endian #70
Comments
I found this quote searching for information on the subject
That seems to imply that the ABI for big endian platforms specify left to right bit-field ordering and left to right ordering for little endian platforms. I think the defaults should reflect this. |
Indeed, this seems to be the case. I didn't know that, and with that in mind, the current default makes sense. But then, I have an issue with the documentation. The
which is wrong. |
The default bits order for a bitfield (without a bitfield_order attribute) is LeastToMostSignificant, but when switching to big endian with
#pragma endian big
, that default seems to change to MostToLeastSignificant.Using this bitfield as an example:
For a file containing a single byte set to 0x01, without any
#pragma
directive, x has a value of 1. With#pragma endian big
, x has a value of 0 (and when I change the content of the file to 0x80, then x becomes 1).Because endianness is about the order of bytes and not about the order of bits, I think keeping the same default for big endian and for little endian would make more sense. LeastToMostSignificant already handles endianness properly (or at least, like I would expect it to). For example, with a file containing
00 00 00 01
, and with the following pattern:, x properly shows the value 1.
The text was updated successfully, but these errors were encountered: