P3
As part of JDK-8219470, jextract is now able to evaluate a #define constant using the clang API; this means that the grammar of the accepted macro constants has increased significantly.
Unfortunately, jextract/binder are not able to handle constants which require allocation - examples:
"Hello" -> Pointer<Byte>
(void*)1 -> Pointer<?>
Since these constants are pointers, they should be allocated, by the bound implementation, with the right Scope. But this information is not available at extraction time.
For strings, we simply return a Java String, which is then incompatible with the other extracted API points; for void pointers, we simply bail out, and omit the macro.
A more robust approach would be to have an annotation specifically dedicated to constants (instead of generating a default method in the extracted interface); the annotation could specify the constant value, and the binder would be in charge of turning that value into the carrier type that is requested by jextract: when the bound implementation is generated by the binder, we have the scope information we need to create pointers.
Unfortunately, jextract/binder are not able to handle constants which require allocation - examples:
"Hello" -> Pointer<Byte>
(void*)1 -> Pointer<?>
Since these constants are pointers, they should be allocated, by the bound implementation, with the right Scope. But this information is not available at extraction time.
For strings, we simply return a Java String, which is then incompatible with the other extracted API points; for void pointers, we simply bail out, and omit the macro.
A more robust approach would be to have an annotation specifically dedicated to constants (instead of generating a default method in the extracted interface); the annotation could specify the constant value, and the binder would be in charge of turning that value into the carrier type that is requested by jextract: when the bound implementation is generated by the binder, we have the scope information we need to create pointers.