BUG: SystemABI C_LONG and C_LONGLONG are the same
youngty1997 at gmail.com
Tue May 19 14:05:21 UTC 2020
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).
> 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.
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.
More information about the panama-dev