Bindings crash on Windows where they would not before

[Jorn Vernee]

 > 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
>
>