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

[Maurizio Cimadamore]

Looked at the jextract patch too.

I'm a bit uneasy with the approach; I'll try to explain why.

You basically convert the struct layout and the var layout _after the 
fact_; that is, we first create layout that are endianness-less. Then, 
just before we write them out, we add endianness back in.

This has some bad consequences - as, I think, it will fail for all 
nested things. I think that, the fact that we are using symbolic 
references (Unresolved layouts) is saving you a little bit here.

e.g.

u64:${foo}

will work, because, when we will have to replace the actual layout of 
'foo' into the above, we will find something that does have an endianness.

But that's mostly an accident. You can have pointer to arrays, too:

u64:[5 i32]

And in this case, withEndianness will do nothing for these.

I think the endianness should be computed on the fly, by LayoutUtils. 
And probably there has to be some state info which tells you whether you 
are generating a function layout (in which case you want to endianness).

But I think LayoutUtils should always push the endianness info down at 
the value components - that is, when it finds a C int type, it will 
figure out what is the platform endianness, and generate either >i32 or 
<i32 - assuming you are not in a toplevel function context.

Maurizio


On 28/02/2019 21:57, Henry Jen wrote:
> Any comment on the jextract patch, good to go or we prefer to modify the annotation of each master file?