2010/3/15 Chris Muller <asqueaker at gmail.com>:
>> I thought I did fix it In my image I have:
>> ^(self next: count into: byteArray startingAt: startIndex) size - startIndex + 1
>>
>> and next:into:startingAt: just return a copy truncated to last byte
>> read, so it relates to size read.
>
> I just committed a test demonstrating the bug to the trunk.  Please
> see testReadIntoStartingAtCount.
>
>> This stupid API was here before us, so we are just maintaining compatibility...
>
> Glad to hear it, right now I just want compatibility too, to get moved to 3.11.
>
>  - Chris
>
>

OK, I see my workaround don't work in all cases.

next: n into: aString startingAt: startIndex
always answer aString if is success reading the n items, and it did it
previously, that did not change...
It truncates only if it fails to read requested count.
It makes sense only when used thru #nextInto:
On the other hand, current stupid implementation prevents performing a
useless copy, except near end of stream...

I will publish a new workaround.

Nicolas