<div dir="ltr">Hi Maurizio, <div><br></div><div>The main reason I was looking at VaList support is because I had a request from someone wanting to use my library that wants to bind to a function that takes this as a parameter: </div><div><br></div><div><a href="https://www.freedesktop.org/software/libevdev/doc/latest/group__logging.html#gab7eb997be2b701cc6f42e7b4c3478269">https://www.freedesktop.org/software/libevdev/doc/latest/group__logging.html#gab7eb997be2b701cc6f42e7b4c3478269</a><br></div><div><a href="https://www.freedesktop.org/software/libevdev/doc/latest/group__logging.html#gaa60be86b83b3a6c82d8e536ba89ff955">https://www.freedesktop.org/software/libevdev/doc/latest/group__logging.html#gaa60be86b83b3a6c82d8e536ba89ff955</a><br></div><div><br></div><div>Considering VaList is being removed in Java 21, is there any way for an upcall to be defined that would be compatible with a va_list argument? I suppose it would be possible to add va_list support to my library manually using the methods you were using in java 19, but that adds some additional complexity to my library.</div><div><br></div><div>Re int vs long, the test there doesn't attempt with Long, but changing `CInt` to `CLongLong` is how I do it. When that's done, the test starts passing without issues on java 17. It's very odd behavior. </div><div><br></div><div>All in all, I'm a bit saddened to hear about VaList support being removed seeing as I just spent the better part of a week and a half adding support for it to my library, but I'll live should that be the final decision on VaList. That being said, it's one of the few things I've been asked for from people wanting to test my library, so I worry that it may be something that's wanted when the foreign api is no longer a preview feature. That being said, maybe I'm just one of the few users of the raw foreign API and everyone else will just use jextract ;)</div><div><br></div><div>Thanks again for your hard work,</div><div>Mark</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 20, 2023 at 11:19 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Mark,<br>
the implementation of VaList has been ironed out a lot around 19 (when <br>
the API became preview) - that said, I don't recall a specific fix for <br>
the issue you mention.<br>
<br>
Also, as mentioned here [1, 2], VaList is no longer part of the API <br>
since 21, as the interaction with a VaList is hopelessly platform <br>
dependent (since different platforms use different encoding for <br>
va_list), meaning that it is very problematic, from a javadoc <br>
perspective, to specify which exception will be issued and when.<br>
<br>
Regarding int vs. long, the C language defines a set of default argument <br>
promotion that should be applied when using variadic functions and <br>
va_lists. The builder methods and getters of the VaList class were <br>
designed with these constraints in mind, which means the calls to the <br>
valist builder have to "match" the calls to the getters (or undefined <br>
behavior will ensue). From the Scala code you paste below, it is not <br>
clear to me is such a mismatch occurs (I do no see `long` anywhere, but <br>
I do see `get[CInt]`).<br>
<br>
Maurizio<br>
<br>
[1] - <br>
<a href="https://mail.openjdk.org/pipermail/panama-dev/2022-November/018096.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/panama-dev/2022-November/018096.html</a><br>
[2] - <a href="https://git.openjdk.org/panama-foreign/pull/763" rel="noreferrer" target="_blank">https://git.openjdk.org/panama-foreign/pull/763</a><br>
<br>
<br>
On 20/04/2023 08:00, Mark Hammons wrote:<br>
> Hi all,<br>
><br>
> I know that the panama project is pushing forward on java 20 and 21 <br>
> right now, and java 17 is probably not a great concern for you all at <br>
> the moment, but I was testing VaList support in my library, Slinc, and <br>
> it seems to be flaky on Java 17.0.5. The test in question goes like so:<br>
><br>
>   property("varargs can be embedded in structs"):<br>
>       forAll: (ints: Seq[CInt]) =><br>
>         val numTake = 8<br>
>         Scope.confined:<br>
>           val va = VarArgsBuilder.fromIterable<br>
>             (<br>
>               ints.map(a => a: Variadic).take(numTake)<br>
>             )<br>
>             .build<br>
><br>
>           val x = va.copy()<br>
><br>
>           val p = Ptr.copy(E(x))<br>
><br>
>           ints.take(numTake).foreach: value =><br>
>             assertEquals(va.get[CInt], value, "conversion test")<br>
><br>
>           ints.take(numTake).foreach: value =><br>
>             assertEquals((!p).list.get[CInt], value)<br>
> Originally in this test I was testing if I could write a VaList to a <br>
> struct and get it back out and pull the values out of it <br>
> appropriately. What I noticed is that if the number of integer values <br>
> in a row passed into VaList is 8 or greater, my test fails. 7 or less <br>
> ints and the test passes. On the Java 19 implementation, this does not <br>
> happen, nor does this happen when I pass a great deal more parameters <br>
> (but more varied in types, some longs, some pointers, some structs). <br>
> This test passes if I randomly generate Long values and pass those <br>
> into the VaList.<br>
><br>
> This is not a critical bug by any means. I can sidestep the issue by <br>
> encoding all lower integral types into Long in the java 17 runtime for <br>
> my library. I just wanted to bring this to your attention because it's <br>
> a weird issue that java 17 users of the foreign api may hit.<br>
><br>
> Thanks for your time,<br>
> Mark Hammons<br>
</blockquote></div>