BUG: SystemABI C_LONG and C_LONGLONG are the same
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
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