I think, yes. How to post request for adding this feature?
2011/11/24 David Brown <david@xxxxxxxxxxxxxxx>:
> 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?
>
>
--
С уважением, Владимир
