<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks to both of you for the additional information on that!</p>
<p>While trying to support arbitrary user-defined typedefs might
indeed be difficult, would it be possible to at least support the
standard fixed-width integer and floating point types (such as `<span
class="t-lines"><span>int16_t`)?<br>
Maybe with an opt-in flag which preserves these types and
generates corresponding constants for them in the generated
`...$shared.java` class?</span></span></p>
<p><span class="t-lines"><span>It seems Clang does provide the
needed information to get the typedef names and not their
underlying type. I have created a proof-of-concept which
demonstrates this here:
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jextract/pull/299">https://github.com/openjdk/jextract/pull/299</a><br>
Hopefully this is useful for you (or anyone else), in case you
weren't aware of it already anyway.</span></span></p>
<p><span class="t-lines"><span>What do you think?</span></span></p>
<p><span class="t-lines"><span>Kind regards</span></span></p>
<div class="moz-cite-prefix">Am 05.01.2026 um 13:01 schrieb Jorn
Vernee:<br>
</div>
<blockquote type="cite"
cite="mid:5a010bc5-1ecf-4500-a3e5-1006030ebe68@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>I had a look at what jextract does in the case of int64_t and
size_t. In both cases these are typedefs for another builtin
type. The former is a typedef for `long` and the latter a
typedef for `unsigned long`. jextract uses the underlying type
of the typedef to determine which layout to use, so we end up
with C_LONG in both cases.<br>
<br>
While these types are semantically portable, their typedefs may
have a non-portable definition, which jextract expands - like a
macro - during extraction. This problem is similar to this
example:<br>
<br>
<font face="monospace">#ifdef WIN32<br>
typedef long long my_int</font><font face="monospace">;<br>
#else<br>
typedef long </font><font face="monospace">my_int</font><font
face="monospace">;<br>
#endif</font></p>
<p>This code is portable in the C sense, but jextract eagerly
picks one of the two branches of this compiler switch when
extracting.</p>
<p>This seems like a tricky issue to workaround. In this case I
think we'd want the type to be 'resolved' at runtime rather than
extraction time, but I don't think we can let jextract collect
all the different definitions of `my_int`, and then pick the
right one at runtime.</p>
<p>Jorn</p>
</blockquote>
</body>
</html>