On Thu, 1 Dec 2022 17:22:49 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/foreign/VaList.java line 56:
>>
>>> 54: * <h2 id="safety">Safety considerations</h2>
>>> 55: * The behavior of any attempts to access a value in the va list,
>>> whether through one of the {@code nextVarg} overloads
>>> 56: * or {@link #skip(MemoryLayout...)}, using a memory layout other than
>>> the layout of the accessed value, or any subsequent
>>
>> Not super sure what you mean here by using a layout "other than the layout
>> of the accessed value". I think you mean the layout of the underlying value
>> that needs to be accessed? Also, is the behavior undefined even when the
>> VaList is created safely, from Java code?
>
> Yes, I mean the layout of the underlying value that is being accessed. i.e.
> can't access a boolean as an int.
>
> The behavior is undefined either way. Even when a VaList is created from
> Java, we create the same underlying native data structure (because we want to
> pass it to native code). This doesn't keep track of the layouts the list was
> built with, so there can still be mismatches.
Right.
-------------
PR: https://git.openjdk.org/jdk/pull/11440
