<div dir="ltr"><div dir="ltr">On Thu, Oct 30, 2025 at 12:11 PM Florian Weimer <<a href="mailto:fweimer@redhat.com">fweimer@redhat.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Also, since there aren't any consistency effects in place, it is not<br>
> deterministic which changes made by the writer would be seen by the<br>
> reader/copier.<br>
<br>
Sure, but if a defensive copy were made, at least the output would be<br>
internally consistent.</blockquote><div><br></div><div>I think this is still missing the bigger picture. I.e., what is "internally consistent" supposed to mean? As Pavel said:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">the array may be changed while it's being copied, which is no different from it being changed while it is being written from.</blockquote></div><div><br></div><div>From a "consistency" point of view, I think the array behaves essentially as a bunch of unrelated 8-bit quantities, all of which are subject to change, in any order. Even if the adversarial writers were writing in some order, the OutputStream method won't necessarily observe those writes in that same order (actually I am not 100% certain, but I'm pretty sure the memory model doesn't guarantee that). So it doesn't matter if OutputStream happens to read the array from 0 to N - that doesn't really impose any "order" so to speak.</div><div><br></div><div>-Archie</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>