BUG: SystemABI C_LONG and C_LONGLONG are the same

[Ty Young]

On 5/14/20 6:38 PM, Maurizio Cimadamore wrote:
>
> 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.


Regardless of intent, people are probably going to do what I'm doing in 
some shape or form. Matching layouts with types just feels natural.


>
> 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.


I was aware of the signed issues and was planning on fixing all the 
little cracks and rough edges once Panama's API becomes more stable. 
It's just too hard to keep up with all the breaking changes between 
versions.


>
> 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).


Couldn't Panama provide a "withSignedness" or something if you don't 
want to have that many constants?


I have to say, the APIs that you are forcing users to use 
(MethodHandles/VarHandles/Constable) are so new, rarely used, and poorly 
documented that it's probably going to scare people away from FMA. I 
understand this is supposed to be a low level API(which is good for 
performance) but it feels almost too raw, like an internal JDK API or 
something.


I have no idea how the Constable API is supposed to work. I briefly 
tried implementing the interfaces only to eventually wind up with a 
method that takes a Lookup object as an input argument. What am I 
supposed to do with it?


>
> 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?


It's primarily used for structs:


https://github.com/BlueGoliath/Crosspoint/blob/master/src/main/java/org/goliath/crosspoint/structs/BasicNativeStruct.java#L65


The bindings structs just use an internal struct and wrap for type safety.


>
> 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();
>>     }
>>