The code generated by jextract requires to use --enable-native-access where it should not

Jonathan Rosenne jr at qsm.co.il
Thu Sep 19 10:45:36 UTC 2024


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 at openjdk.org> On Behalf Of Maurizio Cimadamore
Sent: Thursday, September 19, 2024 1:29 PM
To: Remi Forax <forax at univ-mlv.fr>; panama-dev <panama-dev at openjdk.org>; jextract-dev at 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


More information about the jextract-dev mailing list