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
