VaList is buggy on Java 17?

[Maurizio Cimadamore]

Hi Mark,
the implementation of VaList has been ironed out a lot around 19 (when 
the API became preview) - that said, I don't recall a specific fix for 
the issue you mention.

Also, as mentioned here [1, 2], VaList is no longer part of the API 
since 21, as the interaction with a VaList is hopelessly platform 
dependent (since different platforms use different encoding for 
va_list), meaning that it is very problematic, from a javadoc 
perspective, to specify which exception will be issued and when.

Regarding int vs. long, the C language defines a set of default argument 
promotion that should be applied when using variadic functions and 
va_lists. The builder methods and getters of the VaList class were 
designed with these constraints in mind, which means the calls to the 
valist builder have to "match" the calls to the getters (or undefined 
behavior will ensue). From the Scala code you paste below, it is not 
clear to me is such a mismatch occurs (I do no see `long` anywhere, but 
I do see `get[CInt]`).

Maurizio

[1] - 
https://mail.openjdk.org/pipermail/panama-dev/2022-November/018096.html
[2] - https://git.openjdk.org/panama-foreign/pull/763


On 20/04/2023 08:00, Mark Hammons wrote:
> Hi all,
>
> I know that the panama project is pushing forward on java 20 and 21 
> right now, and java 17 is probably not a great concern for you all at 
> the moment, but I was testing VaList support in my library, Slinc, and 
> it seems to be flaky on Java 17.0.5. The test in question goes like so:
>
>   property("varargs can be embedded in structs"):
>       forAll: (ints: Seq[CInt]) =>
>         val numTake = 8
>         Scope.confined:
>           val va = VarArgsBuilder.fromIterable
>             (
>               ints.map(a => a: Variadic).take(numTake)
>             )
>             .build
>
>           val x = va.copy()
>
>           val p = Ptr.copy(E(x))
>
>           ints.take(numTake).foreach: value =>
>             assertEquals(va.get[CInt], value, "conversion test")
>
>           ints.take(numTake).foreach: value =>
>             assertEquals((!p).list.get[CInt], value)
> Originally in this test I was testing if I could write a VaList to a 
> struct and get it back out and pull the values out of it 
> appropriately. What I noticed is that if the number of integer values 
> in a row passed into VaList is 8 or greater, my test fails. 7 or less 
> ints and the test passes. On the Java 19 implementation, this does not 
> happen, nor does this happen when I pass a great deal more parameters 
> (but more varied in types, some longs, some pointers, some structs). 
> This test passes if I randomly generate Long values and pass those 
> into the VaList.
>
> This is not a critical bug by any means. I can sidestep the issue by 
> encoding all lower integral types into Long in the java 17 runtime for 
> my library. I just wanted to bring this to your attention because it's 
> a weird issue that java 17 users of the foreign api may hit.
>
> Thanks for your time,
> Mark Hammons