On Tue, 5 Jul 2022 15:14:20 GMT, Jorn Vernee <[email protected]> wrote:
>> This seems a bit too much.
>>
>> The class javadoc further up already describes a va list as "a stateful
>> cursor used to iterate over a set of arguments". If that description is
>> insufficient, I think it should be amended at that point.
>>
>> Also, I don't think we have to go into describing how va lists returned by
>> different factories are implemented (in fact, I think we should avoid that
>> in order not to make accidental false promises when things change). It seems
>> like noise next to the safety concerns (if someone really wants to know how
>> the specified semantics are implemented, they can look at the code, or ask
>> on the mailing list).
>>
>> I'd suggest something simpler like this:
>>
>> Suggestion:
>>
>> * It is possible for clients to access elements outside the spatial bounds
>> of a variable argument list. Variable argument list
>> * implementations will try to detect out-of-bounds reads on a best-effort
>> basis.
>> * <p>
>> * Whether this detection succeeds depends on the factory method used to
>> create the variable argument list:
>> * <ul>
>> * <li>Variable argument lists created <em>safely</em>, using {@link
>> #make(Consumer, MemorySession)} are capable of detecting out-of-bounds
>> reads;</li>
>> * <li>Variable argument lists created <em>unsafely</em>, using {@link
>> #ofAddress(MemoryAddress, MemorySession)} are not capable of detecting
>> out-of-bounds reads</li>
>> * </ul>
>> * <p>
>>
>>
>> I'm also fine with changing the section title to "Safety considerations".
>
> i.e. I'd like to just specify the behavior, and avoid explaining why we have
> that behavior.
I've updated the PR with this suggestion for now. Please let me know if it
looks OK to you as well.
-------------
PR: https://git.openjdk.org/jdk19/pull/91
