<div dir="ltr">Thanks Yoshiki,<div><br></div><div>    I&#39;m committing this now<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 6, 2014 at 2:09 PM, Yoshiki Ohshima <span dir="ltr">&lt;<a href="mailto:Yoshiki.Ohshima@acm.org" target="_blank">Yoshiki.Ohshima@acm.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This can be a nitpick of the year, but there is a bug in<br>
InflateStream&gt;&gt;decompressBlock:with:<br>
<br>
There is a part that reads (toward the end):<br>
<br>
------------------------<br>
collection<br>
        replaceFrom: readLimit+1<br>
        to: readLimit + length + 1<br>
        with: collection<br>
        startingAt: readLimit - distance + 1.<br>
------------------------<br>
<br>
but here we want to replace &quot;length&quot; bytes in collection, as opposed<br>
to length + 1 bytes, so it has to say:<br>
<br>
------------------------<br>
collection<br>
        replaceFrom: readLimit+1<br>
        to: readLimit + length<br>
        with: collection<br>
        startingAt: readLimit - distance + 1.<br>
------------------------<br>
<br>
(So is the non-primitive version in FastInflateStream.)<br>
<br>
The reason it does not matter is that replaceFrom:to:with:startingAt:<br>
does not care about the source and destination being the same and<br>
overlap between them.  Even when the above bug puts one extra bytes in<br>
collection temporarily, the extra byte will be wiped out in the next<br>
iteration of the loop surrounding it.  However, if you try to port<br>
this to a language that does the &quot;right thing&quot; when there is an<br>
overlap, it manifests as a bug.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Yoshiki<br>
</font></span><br>
P.S.<br>
It was a &quot;rare&quot; delight to point out a bug in Andreas&#39; code^^; We miss<br>
you.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div></div>