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

[Henry Jen]

> On Feb 26, 2019, at 10:25 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 26/02/2019 17:27, Henry Jen wrote:
>> The test case cover endianness access for short/int/long. Other perspective should have been covered, that’s why I think the test coverage should covering all path added.
>> 
>> The reason I didn’t do jextract is that it doesn’t have to, as I suggested, integral type in programming language has no endianness(as you considering “register”), so they are generated using default construction.
>> 
>> We can certainly take the step to enforce that endianness as jextract time, so that generated artifact can only be used on the same platform, which is the use case we are after anyway.
>> 
>> I didn’t enforce the memory access check because 1) I think that can be done later, as we need to change all test cases manually annotated and 2) I think that’s over-restricted	IMHO, a layout can be “specialized” at memory write time. It’s more a warning at read time if we think implicit is bad.
>> 
>> So I’ll update the webrev for above mentioned changes, and take another spin for adding the check.
> 
> I understand.
> 
> My main point here is that this patch essentially introduces another mechanism to deal with endianness - which is the byte swap syntax. Since we add new complexity to do that, I think I'd like to also _remove_ the complexity associated with the previous way to denote endianness (e.g. upper/lower case letters). By doing so we present a view of the world, after the changeset that is self-consistent.
> 

I will remove the uppercase BIG_ENDIAN notation then. That’s basically what I proposed for endianness in TypeDescriptor spec[1].

[1] https://cr.openjdk.java.net/~henryjen/panama/doc/TypeDescriptor.html

Cheers,
Henry

> I'm less concerned about missing checks - although I'd prefer to see them added sooner rather than later, to validate if the user model we had in mind was in fact correct. These can come separately if that makes things easier for you. But having two different ways to say big endian seems a suboptimal place to be, even if temporarily.
> 
> Thanks
> Maurizio
>