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: Joseph Myers <joseph at codesourcery dot com>
- Cc: Damien Zammit <damien at zamaudio dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 02 Sep 2019 09:14:45 +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>
* Joseph Myers:
> On Fri, 30 Aug 2019, 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.
>
> That seems like a matter of declaring your structure appropriately (with
> the right alignment if e.g. it's being allocated on the stack, or with the
> packed attribute if it might genuinely be at arbitrary alignments; with
> the may_alias attribute if it's necessary for it to alias something with a
> different effective type).
To some degree, yes, but I don't think the GCC internal type system
supports member alignment (and storage order, for the pragma), so you
need to be extremely careful when building abstractions around that. It
doesn't help that all the common targets (from my perspective) do not
have alignment traps, so bugs are difficult to spot.
Thanks,
Florian