[foreign] RFR 8218153: Read/Write of Value layout should honor declared endianness

John Rose john.r.rose at oracle.com
Sun Feb 3 18:49:15 UTC 2019


On Feb 2, 2019, at 7:13 PM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> Now, the union is a host endian value, where in the other fields, we want to store the number in memory as BIG ENDIAN.

The old minimal-ldl proposal has a contextual byte-swapping operator.
Something like that would do the job.  It could take the form of an
endian marker that appears at the beginning of a layout, or on a
group, or just before an individual value (although that functionality
can be covered by using different characters for different endian-ness).

(Random idea:  What if layout letters were NE by default, and only got
BE or LE if they were in the context of an endian prefix?  Then layout
strings could produce NE variables which could be transformed later.
That kind of gets at your use case for HE, without baking it into the
layout strings.  You'd read a bunch of NE layouts and then apply the
contextual setting afterwards.)

> For jextract, there is no way it would know that the ns/nl/nll field is to be stored BIG ENDIAN without extra directive, it only knows it a C type, so what do we generate? I believe this should be “not specified” situation. Let’s assume we use LE as suggest.
> 
> In case we doing it manually, we can specify ns/nl/nll to be BIG ENDIAN with uppercase U. However, we won’t be able to distinguish “LE” and “not specified”.



More information about the panama-dev mailing list