RFR: 8291359: Specification of method j.l.foreign.VaList::skip still deserves clarification [v2]
Jorn Vernee
jvernee at openjdk.org
Thu Dec 1 17:25:00 UTC 2022
On Thu, 1 Dec 2022 17:20:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> Jorn Vernee has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>>
>> Clarify spec
>
> 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.
-------------
PR: https://git.openjdk.org/jdk/pull/11440
More information about the core-libs-dev
mailing list