BUG: SystemABI C_LONG and C_LONGLONG are the same

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon May 18 12:12:33 UTC 2020

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

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.


So, if the bindings are defined correctly, everything else should work.

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


More information about the panama-dev mailing list