Two bugs (missing padding in struct layout / shadowing of existing class names)
Sundararajan Athijegannathan
sundararajan.athijegannathan at oracle.com
Tue Jul 16 11:21:51 UTC 2024
Hi,
Thanks for reporting these issues.
I've filed two bugs:
https://bugs.openjdk.org/browse/CODETOOLS-7903777
https://bugs.openjdk.org/browse/CODETOOLS-7903776
Thanks,
Sundar
________________________________
From: jextract-dev <jextract-dev-retn at openjdk.org> on behalf of rafaeldaetwyler <rafael.daetwyler at gmail.com>
Sent: 16 July 2024 14:35
To: jextract-dev at openjdk.org <jextract-dev at openjdk.org>
Subject: Two bugs (missing padding in struct layout / shadowing of existing class names)
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/4ff7f885/attachment.htm>
More information about the jextract-dev
mailing list