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

[Henry Jen]

I feel like it’s a "you say tomato, I say tomahto” situation. By platform endian, it’s like “not specified”. I can agree that’s more abroad than “no endianness”.

I like (3) and can work with that. But I am not certain if the descriptor can mean both “LE” and “no endianness” as suggested. 

Let’s assume a C struct as we see in the test program, 

struct HostNetworkValues {
  union {
    uint16_t hs;
    uint32_t hl;
    uint64_t hll;
  };
  uint16_t ns;
  uint32_t nl;
  uint64_t nll;
};

Now, the union is a host endian value, where in the other fields, we want to store the number in memory as BIG ENDIAN.

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

However, I am sensing that perhaps you meant we only apply the magic to function descriptor, and for struct/union, if always will be explicit. That is, no “not specified” option, then the descriptor generated for the union by jextract will be different depends on the platform endian jextract is running on.


> On Feb 2, 2019, at 2:43 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> Summing up - I believe the bug is not in DirectNativeInvoker "ignoring" the endianness, but in UniversalInvoker taking it into account (because UniversalInvoker relies on Pointer API which relies on byte ordering). But the Pointers that Universalinvoker has to manipulate are, morally, sequence of longs that need to be passed either in registers or in stack slots - so I don' think we want to create those with endianness-ful layouts - and we should of course check that SystemABI throws whenever a NativeMethodType is passed where one of the layout has an explicit endianness (the same way as we now throw when we pass a NMT that contains an array carrier).
> 

I am fine with limiting ENDIANNESS on function, as I don’t expect that offer much value. Just to clarify though, UniversalInvoker is create longs be passed into the bridge function as host endian, the endianness is expressed for incoming Java argument.

Cheers,
Henry