<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi,<br>
your solution seems good -- e.g. using canonical layout with type
names like int16_t is the right direction.</p>
<p>The problem is that doing so doesn't yet get us out of the woods
-- because there's still C_LONG to worry about.</p>
<p>In your patch, you seem to address this by "downgrading" C_LONG
to a ValueLayout. This obviously works, but if we did this for
every binding, existing jextracted code using C_LONG would no
longer work -- because now the layout of C_LONG would not be sharp
enough to allow you to use it inside e.g. a MemorySegment::get
call.</p>
<p>I think some other tactic is needed here -- either a flag that
disables/filters generation of primitive layouts (these are not
defined in any header, so filtering at the moment is not really
possible). Or adding some kind of magic auto-filtering (e.g. if
C_LONG is not used anywhere, just omit it from the bindings).</p>
<p>The first option is probably the simplest -- we already have many
"--include-XYZ" -- maybe also adding "--include-builtin=long"
would be ok. Although, this might create incompatibities in cases
where users have already saved the include list somewhere -- e.g.</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/linux/gen_linux.sh">https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/linux/gen_linux.sh</a></p>
<p>E.g. currently jextract users assume that builtin types will
_always_ be emitted. The change described above would alter that.</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 25/01/2026 22:38,
<a class="moz-txt-link-abbreviated" href="mailto:some-java-user-99206970363698485155@vodafonemail.de">some-java-user-99206970363698485155@vodafonemail.de</a> wrote:<br>
</div>
<blockquote type="cite" cite="mid:afa44df4-d471-4efa-9620-4da1f3054473@vodafonemail.de">
<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" moz-do-not-send="true">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">
<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>
</blockquote>
</body>
</html>