This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Host endian independence
- From: Florian Weimer <fweimer at redhat dot com>
- To: Damien Zammit <damien at zamaudio dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 02 Sep 2019 09:12:43 +0200
- Subject: Re: Host endian independence
- References: <18c8a820-b2c4-8ab2-58d1-8d8c851dbf01@zamaudio.com> <alpine.DEB.2.21.1908271544290.18629@digraph.polyomino.org.uk> <878srb6jmh.fsf@oldenburg2.str.redhat.com> <alpine.DEB.2.21.1908301611520.5568@digraph.polyomino.org.uk> <f93b1ed9-de55-5615-b0ec-8e64db972fb5@zamaudio.com>
* Damien Zammit:
> On 31/8/19 2:22 am, Joseph Myers wrote:
>> The scalar_storage_order attribute could certainly be added to an
>> appropriately declared structure to move the endianness information
>> entirely into how the structure is defined and out of the code using the
>> structure.
>
> I was not aware of this attribute until now, but looks like the best
> approach to me. I might put together a new proof of concept and send
> in a new set of patches for review.
You need to be careful where you use this features. Some shared code
cannot use features which are GNU C only (not even the C++ frontend
supports it). And it's always a bit risky to be an early adopter of
such compiler extensions.
> Florian Weimer wrote:
>> The problem with the existing interfaces is that that they make it hard
>> to take alignment issues into account. See bug 20243. When used for
>> parsing packet buffers, they also tend to introduce aliasing violations.
>
> I had a quick look at bug 20243, would it also be fixed by using the
> "packed" attribute and Joseph's idea of putting the endianness info in
> the definition of the structs with the "scalar_storage_order"
> attribute?
Note that either case will need a new struct definition.
Thanks,
Florian