This is the mail archive of the
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: <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org>
* 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
> 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"
Note that either case will need a new struct definition.