Details
-
Bug
-
Resolution: Fixed
-
P3
-
None
-
repo-panama
Description
Jextract generates a bunch of layouts to deal with C types (C_INT, C_FLOAT, ...).
These layouts have the correct size and alignment, depending on the platform in which jextract is ran.
Unfortunately, the struct layouts and function descriptors emitted in jextract constant classes end up relying on Java layouts instead (JAVA_INT, JAVA_FLOAT, ...).
Not only this is aesthetically unpleasing - but it is also a potential correctness issue, given that the alignment of Java types might differ from those of C types. For instance, in Java 18, JAVA_INT (and all other layouts) have alignment of 1-byte. But even in Java 17, JAVA_DOUBLE can have alignment of 4 on x86 platforms.
Probably the best way to resolve this is to change the generated code as follows:
1) move C_INT and friends to constant_0
2) have every layout and function descriptors in constant_0 refer to those (e.g. assume they are there)
3) redefine the "typedefs" in foo_h.java to point to the basic C layouts in constant_0
These layouts have the correct size and alignment, depending on the platform in which jextract is ran.
Unfortunately, the struct layouts and function descriptors emitted in jextract constant classes end up relying on Java layouts instead (JAVA_INT, JAVA_FLOAT, ...).
Not only this is aesthetically unpleasing - but it is also a potential correctness issue, given that the alignment of Java types might differ from those of C types. For instance, in Java 18, JAVA_INT (and all other layouts) have alignment of 1-byte. But even in Java 17, JAVA_DOUBLE can have alignment of 4 on x86 platforms.
Probably the best way to resolve this is to change the generated code as follows:
1) move C_INT and friends to constant_0
2) have every layout and function descriptors in constant_0 refer to those (e.g. assume they are there)
3) redefine the "typedefs" in foo_h.java to point to the basic C layouts in constant_0
