On 23/11/2011 19:33, Владимир Андреев wrote:
Hello all!
I have some lack of understanding how to write endianness independent
definition of structure, which contains bit fields.
For example, field, containing endpoint address in endpoint descriptor
of USB device, can be defined as follow:
struct EndpointAddress
{
UnsignedByte EndpointNumber: 4;
UnsignedByte: 3;
UnsignedByte TransferDirection: 1;
};
All USB descriptors have little endian byte order (and filling
starting from least significant bit). If I would run some code which
uses such definition on big endian CPU, I will get incorrect result.
Can I tell GCC to use for layout big/little endian mode without manual
changing structure layout for target CPU?
Unfortunately, no.
It would be /really/ nice if there were a gcc attribute that could
specify that. Ideally you'd have something like
"__attribute__((bitorder(lsbfirst)))", with other options such as
"msbfirst", and "native". I don't know whether that would involve major
effort, or whether it could be handled as a simple front-end
manipulation (basically treating the definition as though you'd included
all implicit padding bits, and then reversed the order).
Note that you can't call this "little-endian bit ordering" and
"big-endian bit ordering" - the bit ordering is independent of the
endianness.
One issue to consider, however, is bitfields that are greater than one
byte - do they change endianness? There are a number of options to
consider.
A related issue is endianness of data - and I think that would be even
more useful as an attribute, but would involve many more changes. I
have seen such an idea on other compilers, so it certainly can be done.
I couldn't see any enhancement requests for something like this in the
bugzilla list, but I'm sure it is something that could be useful to many
people (especially for embedded programming). Perhaps it is worth adding?
