BUG: SystemABI C_LONG and C_LONGLONG are the same

[Ty Young]

On 5/18/20 7:12 AM, Maurizio Cimadamore wrote:
>
> On 18/05/2020 12:55, Ty Young wrote:
>> What if some other API already uses that attribute? Or if it's set to 
>> something completely invalid? 
>
> So is the problem you are trying to solve to defend against users 
> potentially (ab)using your API by creating structs with value layouts 
> which do not contain the attribute you want? Well, we have the same 
> issue with ABI constants - e.g. a user can attempt to create a 
> MethodHandle with a bunch of plain layouts which contain no ABI 
> classfication (or wrong classification).


Yep.


>
> In practice, I'm not sure how much of a problem this really is - as 
> you demonstrated elsewhere, your bindings are in control for defining 
> the layout e.g.
>
> https://github.com/BlueGoliath/java-nvidia-bindings/blob/3445ea5dc42e3901942a328a4d990cde288d55e7/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/structs/nvmlProcessUtilizationSample_t.java#L13 
>
>
> So, if the bindings are defined correctly, everything else should work.


Creation of generic array/struct/union types that just put 
"structure"(pun not intended) to memory is supported too. I want it to 
be open ended. That struct and others like it is just to provide type 
safety. I wish, honestly, that Java had a way to simply alias a class or 
interface so that you can provide additional type-safety without doing 
some variation of inheritance... but it doesn't.


>
> And, in case you allow constructing structs from user-defined layouts, 
> well, it's up to your factory to validate that the layouts seem to 
> make sense (e.g. feature the required carrier info). If they don't, 
> you can just fail on construction. But there will always be things 
> that you won't be able to detect - e.g. if I give you a 32-bit 
> layouts, but I made a mistake and I attched the NativeInteger carrier 
> when in reality the field was a float, how do you catch that? The 
> layout seems to make sense... but I think some tolerance for mistakes 
> is unavoidable here.


I guess so.


>
> I'm honestly not very convinced that, if your objective is to define 
> am higher-level API than what Panama provides, then you need to have 
> low-level exported factories which allow users to build a struct 
> directly from a layout. The way I'd do it perhaps, if I really wanted 
> to hide Panama abstractions from the user would be to use a 
> builder-like API. At which point no mistake is possible from the user 
> side - heck the user can't even pass layouts to the API anymore.


I don't think hiding low level Panama details is the way to go about 
things, and I hope that if Panama does add a higher level API, it 
doesn't go the route of trying to directly model C code like "Pointer" 
kinda sorta did.


I'd personally like to see something like I did, but I'm both biased and 
realize it's probably unrealistic. The amount of classes that this 
otherwise thin abstraction layer is a bit much for the JDK. In my 
defense, the type specific values and arrays only exist because Java 
doesn't support primitive generics.


It would be interesting to get a wider perspective on which approach is 
better. Do people think a smaller higher-level API is better which has 
more "god-like" objects or is a more thinly spread, targeted, and lots 
of classes better? I largely stand by the way I went about it, but I'm 
still personally interested in what others prefer and think.




>
> Maurizio
>