Bindings crash on Windows where they would not before

[jextract at xpple.dev]

Thank you for the responses!

> Maybe the problem is that you are trying to generate Windows bindings 
> from a Linux machine? [...]. It probably just happened that you never 
> worked with libraries using `long` (which, for the portability issues 
> you noted, is often avoided).

You could say that. Although, yes it is indeed the case the `long` type 
is not used in my case, so there should not be any real problems.

> As a workaround, you could try deleting the layout for `C_LONG` in the 
> generated bindings.

I thought of that too, but it is kind of manual (not ideal to automate). 
Since I am generating the bindings on GitHub Actions, it would be 
preferable if there were a more directly supported fix. Perhaps a CLI 
parameter to apply the lenience as described by Maurizio?

> Perhaps, a slightly more lenient way to handle this would be to just 
> leave the layouts to `null` if there's a mismatch (instead of 
> throwing).

Kind regards,


Frederik van der Els

On 2025-03-31 13:11, Jorn Vernee wrote:
>> It probably just happened that you never worked with libraries using 
>> `long`
> 
> I think this is probably the case as well. As a workaround, you could
> try deleting the layout for `C_LONG` in the generated bindings. If the
> library is indeed portal enough, there should be no compilation
> errors.
> 
> Jorn
> 
> On 31-3-2025 11:02, Maurizio Cimadamore wrote:
>> Hi,
>> thanks for the report.
>> 
>> I think the fix should still take into account for platform 
>> mismatches. Note that we now have a shared section, containing 
>> constants  for all platforms) and a follow up sections where we 
>> initialize platform-specific constants.
>> 
>> The shared section only contains LONG_LONG, which is always 64 bits, 
>> even in Windows.
>> 
>> The followup section contains LONG, which is 32bit/OfInt on Windows, 
>> and 64bit/OfLong elsewhere. What the follow up section does is 
>> determined by `TypeImpl.IS_WINDOWS`, which is defned here:
>> 
>> https://github.com/openjdk/jextract/blob/master/src/main/java/org/openjdk/jextract/impl/TypeImpl.java#L45C1-L45C98 
>> So, on Windows the right thing should happen.
>> 
>> Maybe the problem is that you are trying to generate Windows bindings 
>> from a Linux machine? While the code used to work differently (e.g. no 
>> class cast exception), the bindings might behave unpredictably on 
>> Windows. It probably just happened that you never worked with 
>> libraries using `long` (which, for the portability issues you noted, 
>> is often avoided). If you have e.g. a struct containing a long field, 
>> the size and offsets of that struct would be completely bogus, so I 
>> would not recommend to use jextract in that cross-platform way -- it 
>> is not designed to work that way. The new error message points this 
>> out a little earlier (before something worse occurs).
>> 
>>> For instance the platform check could be done at runtime.
>> 
>> Yes, but at the end of the day we have to assign either a `OfLong` 
>> field, or a `OfLongLong` field. And we can't change the type of the 
>> field at runtime. Which means the type of the field is picked at 
>> extraction time (this was also the case before the fix), and at 
>> runtime we cast whatever `canonicalLayout` returns to the expected 
>> type (which throws if there is a mismatch).
>> 
>> Perhaps, a slightly more lenient way to handle this would be to just 
>> leave the layouts to `null` if there's a mismatch (instead of 
>> throwing). This means that bindings only using "portable" layouts 
>> would still work. But, while this might fix your issue, I'm not 100% 
>> sure that would be much better in the general case.
>> 
>> Maurizio
>> 
>>