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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Feb 26 18:25:48 UTC 2019


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'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



More information about the panama-dev mailing list