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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Feb 27 00:07:23 UTC 2019


On 26/02/2019 23:49, John Rose wrote:
> On Feb 26, 2019, at 3:19 PM, Henry Jen <henry.jen at oracle.com> wrote:
>> Also added a test  and localizeLayout() for group layouts, and a Util method when we need to convert no-endian to explicit endianness.
> If localizeLayout is useful as a public API point it should be on the interface.
>
> If not, it should be package-private or static in Util.

Actually - I was thinking about this: we have a 'withEndianness' in 
Value - I wonder if withEndianness should be in Layout (the root), and 
have @Overrides which do the right thing.

At which point, localize(Layout) can be simply expressed as 
Layout::withEndianness(Endianness.hostEndian())

I'd suggest that withEndianness should alter endianness of existing 
layouts which do *not* have endianness, but should throw when changing 
endianness of something that already has an endianness of a different 
polarity.

That is, this is a tool/API to add endianness info 'after the fact', 
which is useful especially when writing Layouts programmatically:

Sequence seq = Sequence.of(
             Group.ofStruct(
                    Value.ofSignedInt(32),
                    Padding.of(8)
                    Value.ofFloatingPoint(32),
             ), 20); // [ 20 [ i32 x8 f32 ] ]


Now, one way to add endianness would be to add explicit endianness to 
every Value factory call, but you can see how in composite layouts 
there's a risk this might not scale well - what, as the user, I'd like 
to be able to do, is just:

Sequence seq = .... some complex layout creation ...
                              .withEndianness(Endianness.LE);


And that will give me what I want - which preserves the readability of 
the original code, and the correctness of having explicit endianness 
everywhere, at the expense of creating a bunch of extra garbage for the 
GC which should hopefully be able to handle w/o too many headaches :-)

Maurizio

>
> In the present form, it seems like implementation is poking irregularly out of the API.
>
> — John


More information about the panama-dev mailing list