<div dir="ltr">Hi,<div><br></div><div>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.</div><div>To reproduce, run<br>- on Linux: jextract <file>.h<br>- on Windows: jextract.bat <file>.h</div><div><font face="arial, sans-serif">on a x86-64 machine using <span style="color:rgb(0,0,0)">Build 22-jextract+5-33.</span></font></div><div><br></div><div><b>1. Struct generation (struct.h)</b></div><div>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.</div><div>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. </div><div>On Windows, a padding is inserted after the C_INT layout.</div><div><br></div><div><b>2. Generation of variables with existing name (boolean.h)</b></div><div>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.</div><div><br></div><div>Best,</div><div>Rafael</div></div>