On Fri, 19 May 2023 23:08:00 GMT, Paul Sandoz <psan...@openjdk.org> wrote:

>>> This look much better. Can we strengthen the specification of 
>>> `canonicalLayouts` in accordance with the class specification
>> 
>> We can't do more in that method javadoc,  think, as that has to be general 
>> enough for all linkers. I think the rules set up in that method javadoc are 
>> good - e.g. the set of layouts should be stable (both in terms of names and 
>> layout types).
>> 
>> What we can do is to sprinkle some wording in the `nativeLinker` factory - 
>> e.g. `the native linker is guaranteed to provide canonical layouts for basic 
>> C types <link to the class section>`.
>
>> > This look much better. Can we strengthen the specification of 
>> > `canonicalLayouts` in accordance with the class specification
>> 
>> We can't do more in that method javadoc, think, as that has to be general 
>> enough for all linkers. I think the rules set up in that method javadoc are 
>> good - e.g. the set of layouts should be stable (both in terms of names and 
>> layout types).
>> 
>> What we can do is to sprinkle some wording in the `nativeLinker` factory - 
>> e.g. `the native linker is guaranteed to provide canonical layouts for basic 
>> C types <link to the class section>`.
> 
> Yes, that's better.

@PaulSandoz after thinking some more, it seems a bit ad-hoc to guarantee a 
canonical for "unsigned short", but not for other unsigned types? Possible 
alternatives (beside keeping what we have in this PR):

* guarantee also all the other unsigned types (e.g. char, int, long and long 
long)
* do not guarantee unsigned short - but provide a mapping for it anyways
* do not guarantee unsigned short, and do not provide a mapping for it - this 
means that JAVA_CHAR will not be usable when linking

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1558110434

Reply via email to