Two bugs (missing padding in struct layout / shadowing of existing class names)

[Jorn Vernee]

I had a look at the struct.h example on Windows. Note that the C 
standard specifies that the value of an enum constant must fit inside an 
'int'. On Windows this seems to be enforced, and as a result, the size 
of EnumDef_Big is 4 bytes. This matches the behavior of MSVC, so what 
jextract does looks correct there.

On Linux, there seems to be an extension for larger enum constants, and 
the size of EnumDef_Big is 8 bytes. But, due to a bug in jextract, we 
are always using the type of the first constant of the enum, hence, we 
get a field of type C_INT, whose 'size' is 8 bytes, which leads to a 
mis-aligned second field. That is something we can fix relatively easily 
though (clang gives us the right information, we just need to use it).

Jorn

On 16-7-2024 11:05, rafaeldaetwyler wrote:
> Hi,
>
> I didn't find an issue tracker, therefore I hope to reach out through 
> the correct channel. I am using jextract for a project and stumbled 
> upon two bugs recently. I narrowed them down to be reproducible using 
> the two header files attached.
> To reproduce, run
> - on Linux: jextract <file>.h
> - on Windows: jextract.bat <file>.h
> on a x86-64 machine using Build 22-jextract+5-33.
>
> *1. Struct generation (struct.h)*
> This bug occurs only on Linux. The layout which is generated for the 
> struct (in structType.java) is comprised of a C_INT (for the enum) and 
> C_LONG (for the uint64_t), without the necessary padding of 4 bytes 
> after the C_INT. This results in a runtime error.
> Since the enum can take a value of both -1 and 0x80000000, an int32 is 
> not enough to hold all values. Therefore, the layout should probably 
> be C_LONG for the enum, too.
> On Windows, a padding is inserted after the C_INT layout.
>
> *2. Generation of variables with existing name (boolean.h)*
> When generating the code, the wrapper class Boolean is shadowed by the 
> generated variable Boolean. The code doesn't compile because the line 
> "static final boolean TRACE_DOWNCALLS = 
> Boolean.getBoolean("jextract.trace.downcalls");" is interpreted as an 
> illegal forward reference. This problem probably applies to all class 
> names in java.lang, as those are automatically imported. It could be 
> solved by applying a suffix to those names. One might argue that 
> variables shouldn't be named like this in the first place, but when 
> using an external library, variable names are already given and would 
> need to be renamed manually.
>
> Best,
> Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20240716/37038267/attachment-0001.htm>