BUG: SystemABI C_LONG and C_LONGLONG are the same

[Maurizio Cimadamore]

On 15/05/2020 00:15, Ty Young wrote:
> Currently with the newest builds SystemABI C_LONG and C_LONGLONG are 
> the same:
>
>
> System.out.println(SystemABI.C_LONG.equals(SystemABI.C_LONGLONG));
This should only be true in a platform where they are the same thing. It 
shouldn't be true on Windows.
>
>
> prints true.
>
>
> Since C_LONG can be 32-bit, it should, IMO, be decoupled from 
> C_LONGLONG. This also breaks my abstraction layer as if ladders like 
> this hit C_LONG always on Linux:

We made the decision that using layouts to model primitive types was not 
the best way to split the ABI support from the abstractions built on 
top. An ABI layout is just that, a layout plus some ABI classification 
information which allows you to describe the signature of the native 
function you wanna call. It is _not_ a substitute for a full blown C type.

While what we had before _happened_ to work in your case, if you kept 
pulling on that string you would have found that e.g. the layout for 
unsigned int and that for int were one and the same - so if a client 
cared about that distinction it would have been equally broken. Hence 
the decision to expose a set of constants which contains the minimal set 
of information that is necessary for the ABI machinery to do the 
classification - no more, no less. There's no attempt to capture the 
semantics of what the type does - and the name similarity (e.g. C_INT) 
is there merely to help clients out when they want to put a 
FunctionDescriptor together by reading the signature of some C function 
that they want to model.

If you want layouts that keep track of the source C type they come from, 
I suggest you add your own layout constants (derived from the basic ABI 
ones) - e.g. by adding static layout fields to NativeByte/Short... and 
friends. The layout attribute machinery is now open - so you are free to 
add whatever metadata you see fit. At some point we did that in jextract 
- but then we also stopped as we didn't really see a lot of value (since 
the AST generated by jextract has a lot of other meta information about 
types).

More generally, I'm a bit dubious about the usefulness of the factory 
you mentioned - it's like if you asked "give me Number instance given a 
byte size" - yes, maybe you can exploit subtle differences in equality 
between the various layouts to get to the answer you want - but it seems 
to me that the question is fundamentally ambiguous, as there are always 
going to be multiple types with same size (and related properties).

I've tried to look around here:

https://github.com/BlueGoliath/GoliathEnvious

But couldn't find any usage of that factory - how do you envision it to 
be used by clients?

Maurizio


>
>
> public static <T extends Number, E extends AbstractNativeNumber<T>> E 
> fromLayout(ValueLayout layout)
>     {
>         if(layout.equals(SystemABI.C_CHAR))
>             return (E)new NativeByte();
>         else if(layout.equals(SystemABI.C_SHORT))
>             return (E)new NativeShort();
>         else if(layout.equals(SystemABI.C_INT))
>             return (E)new NativeInteger();
>         else if(layout.equals(SystemABI.C_FLOAT))
>             return (E)new NativeFloat();
>         else if(layout.equals(SystemABI.C_DOUBLE))
>             return (E)new NativeDouble();
>         else if(layout.equals(SystemABI.C_LONG))
>             return (E)new NativeLong();
>         else if(layout.equals(SystemABI.C_LONGLONG))
>             return (E)new NativeLongLong();
>
>         throw new UnsupportedOperationException();
>     }
>