On Mon, 22 May 2023 09:34:53 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org>
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
>> (Linux/x64) I get this:
>>
>>
>> jshell> import java.lang.foreign.*;
>>
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32,
>> long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16,
>> int32_t=i32, short=s16, double=d64}
>>
>>
>> This can be useful to discover the ABI types supported by a linker
>> implementation, as well as for, in the future, add support for more exotic
>> (and platform-dependent) linker types, such as `long double` or `complex
>> long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Address further review comments
> On further reflection i think mapping C `unsigned short` only to Java `char`
> is a misleading. Although Java `char` is an integral type is not really
> intended to be used generally as an unsigned 16-bit integer, so arguably Java
> `char` is not as useful a carrier type for native interoperation as Java
> `short` might be even though it is signed. Thus i am inclined to remove that
> mapping.
>
> What if we say something to the effect of:
>
> > unless explicitly declared in the canonical layouts C's unsigned integral
> > types are mapped to the layouts associated with the required C's signed
> > integral types of the same bit sizes.
>
> ?
>
> Arguably C `unsigned short` could map to carriers Java `short` or Java
> `char`, but i am inclined to say the user should cast between Java `short` to
> `char` in such cases.
>
> FWIW i checked what the FFM API and jextract does today and it maps unsigned
> C types to signed Java types.
> On further reflection i think mapping C `unsigned short` only to Java `char`
> is a misleading. Although Java `char` is an integral type is not really
> intended to be used generally as an unsigned 16-bit integer, so arguably Java
> `char` is not as useful a carrier type for native interoperation as Java
> `short` might be even though it is signed. Thus i am inclined to remove that
> mapping.
>
> What if we say something to the effect of:
>
> > unless explicitly declared in the canonical layouts C's unsigned integral
> > types are mapped to the layouts associated with the required C's signed
> > integral types of the same bit sizes.
>
> ?
>
> Arguably C `unsigned short` could map to carriers Java `short` or Java
> `char`, but i am inclined to say the user should cast between Java `short` to
> `char` in such cases.
>
> FWIW i checked what the FFM API and jextract does today and it maps unsigned
> C types to signed Java types.
I tend to agree with your conclusion. And I confirm that we do not use "char"
anywhere in jextract. The only "problem" with that approach is that if we go
down that path, JAVA_CHAR is no longer a canonical type, so users cannot
mention it in function descriptors. Apart from requiring few test updates, I
don't see many other problems with it - if one really really wanted the result
of a native call to be converted to `char`, a MH adapter can be used.
Effectively, what you suggest amount at saying: we do have a JAVA_CHAR layout,
which is mostly there for Java interop. But a native linker (which only cares
about native interop) doesn't really care much about that. Does that sound good?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1560086050
