This is the mail archive of the
mailing list for the glibc project.
Re: Host endian independence
- From: Damien Zammit <damien at zamaudio dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Sun, 1 Sep 2019 19:26:32 +1000
- Subject: Re: Host endian independence
- References: <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org>
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.
I'm not expecting it to be merged as is, as you said, Joseph, it would need
to be carefully considered and tested - I think it would be good to have something to test.
Does libc-alpha have a mailing list convention for sending patches in that are WIP?
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
Florian Weimer wrote:
> Obviously, packet parsing and generation should be done with a
> higher-level abstraction and not these read/write functions, to enforce
> error checking, but these functions could serve as a building block for
Neither code like endian-helpers.h nor byte-swapping interfaces seem needed if we use this
attribute and packed structs. Endianness issues can be solved cleanly and most byte-swapping
in the code can be removed.
Florian, what do you think of using a "scalar_storage_order" and "packed" approach?
Thanks for all the ideas and great answers.
damien AT zamaudio.com