Re: Host endian independence

[Damien Zammit <damien at zamaudio dot com>]

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.
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
"scalar_storage_order" attribute?

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
> that.

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 Zammit
damien AT zamaudio.com