Re: The code generated by jextract requires to use --enable-native-access where it should not
(adding jextract-dev) Hi Remi, you bring up a good point, one we were also thinking ourselves. Currently, jextract assumes that you want "loose" safety when working with pointers. That is, say you call a binding for a native function returning a `char*`. You can immediately call `MemorySegment::getString` on the segment returned by that binding, because jextract automatically resize all pointer segments to `Long.MAX_VALUE`. Then, since the "unsafe" address layout is saved into a static final field of the main header class, the restricted operation required to create such layout will be called no matter what. This is why you get the restricted warnings. So, there's really two questions here: * should jextract assume that developers want "unsafe" behavior by default? This seemed a good assumption at first (to avoid too many reinterpret calls from clients), but I can some developers being happy with being "more in control" of where/how resizes occur; * assuming we want to preserve the existing "loose" behavior, should we tweak the generated code so that an unsafe pointer layout is only created when needed (as opposed to always, like now) ? Of these, I think the first question is more interesting than the second (which seems small matter of e.g. "making initialization of the unsafe layout more lazy"). What do people think? Maurizio On 18/09/2024 22:01, Remi Forax wrote:
Hello, the code generated by jextract should be re-arranged so it only requires to use --enable-native-access when the user uses a function that can violate the integrity.
Currently, if a .h only contains a simple struct, like struct point { int x; int y; };
jextract generates two java classes, point and point_h, point describe the structures and point_h the library, but because point has a runtime dependency on point_h, a code like
import point; import point_h;
try(var arena = Arena.ofConfined()) { var p = point.allocate(arena); point.x(p, 42); System.out.println(point.x(p)); }
requires to use --enable-native-access even if using a layout does not violate the integrity of the application/platform.
regards, Rémi
One cannot rely on the C code being proper or safe. The C code may define an array of a single int but actually use it for a much larger array, or even use the variable for a completely different purpose. This is a "feature" of C, after all. So the default of jextract should not be changed. However, if the user of jextract is certain that it is safe, then it is conceivable to provide such an option, whether global or specific to a specific pointer. Best Regards, Jonathan Rosenne -----Original Message----- From: jextract-dev <jextract-dev-retn@openjdk.org> On Behalf Of Maurizio Cimadamore Sent: Thursday, September 19, 2024 1:29 PM To: Remi Forax <forax@univ-mlv.fr>; panama-dev <panama-dev@openjdk.org>; jextract-dev@openjdk.org Subject: Re: The code generated by jextract requires to use --enable-native-access where it should not (adding jextract-dev) Hi Remi, you bring up a good point, one we were also thinking ourselves. Currently, jextract assumes that you want "loose" safety when working with pointers. That is, say you call a binding for a native function returning a `char*`. You can immediately call `MemorySegment::getString` on the segment returned by that binding, because jextract automatically resize all pointer segments to `Long.MAX_VALUE`. Then, since the "unsafe" address layout is saved into a static final field of the main header class, the restricted operation required to create such layout will be called no matter what. This is why you get the restricted warnings. So, there's really two questions here: * should jextract assume that developers want "unsafe" behavior by default? This seemed a good assumption at first (to avoid too many reinterpret calls from clients), but I can some developers being happy with being "more in control" of where/how resizes occur; * assuming we want to preserve the existing "loose" behavior, should we tweak the generated code so that an unsafe pointer layout is only created when needed (as opposed to always, like now) ? Of these, I think the first question is more interesting than the second (which seems small matter of e.g. "making initialization of the unsafe layout more lazy"). What do people think? Maurizio On 18/09/2024 22:01, Remi Forax wrote:
Hello, the code generated by jextract should be re-arranged so it only requires to use --enable-native-access when the user uses a function that can violate the integrity.
Currently, if a .h only contains a simple struct, like struct point { int x; int y; };
jextract generates two java classes, point and point_h, point describe the structures and point_h the library, but because point has a runtime dependency on point_h, a code like
import point; import point_h;
try(var arena = Arena.ofConfined()) { var p = point.allocate(arena); point.x(p, 42); System.out.println(point.x(p)); }
requires to use --enable-native-access even if using a layout does not violate the integrity of the application/platform.
regards, Rémi
On 19/09/2024 11:45, Jonathan Rosenne wrote:
One cannot rely on the C code being proper or safe. The C code may define an array of a single int but actually use it for a much larger array, or even use the variable for a completely different purpose. This is a "feature" of C, after all. So the default of jextract should not be changed. However, if the user of jextract is certain that it is safe, then it is conceivable to provide such an option, whether global or specific to a specific pointer.
I suppose what I’m asking is a bit different - e.g. not saying we should trust all C pointers. More the opposite. Say we have a C function like this: |char* API_VERSION(void); | Then jextract will generate a binding for it, like so: |MemorySegment API_VERSION(); | The question is: how do you interact with this binding? In the current “unsafe” world you can do this: |String apiVersion = API_VERSION.getString(0); | Note that, for this to work, you need an unsafe derefrence of the pointer returned by the C function. This is why jextract code needs “—enable-native-access”. An alternative would be to just leave C pointers as zero-length memory segments [1]. So that this code: |String apiVersion = API_VERSION.getString(0) // throws IndexOutOfBounds | Will fail - as we’re attempting to read from a segment whose size is zero. Instead, this would be required: |String apiVersion = API_VERSION.reinterpret(someLength).getString(0) // ok | What is |someLength| ? Maybe the client knows - however, in most cases, esp. for strings, my feeling is that the client does not know (which is why we opted for unsafely reinterpreting all C pointers to Long.MAX_VALUE). And, note that we have just moved where the unsafe operation occurs: instead of having the unsafe resize happen inside jextract generated code, the resize here would be explicit in the client code. So it’s not like the resulting code would be any safer, just more explicit (which, for some use cases, might be a good thing). Maurizio
participants (2)
-
Jonathan Rosenne
-
Maurizio Cimadamore