You mentioned an interesting point there:
*If implementations actually follow that documentation, [...]*
>
I know that at least some libraries (f.e. "org.apache.commons.io") only
stop reading when -1 is returned and will continue reading if 0 is returned.
That behaviour is definitely more friendly towards implementations that
don't follow the java-doc exactly.
@ Alex Miller:
To cover both cases, maybe take the buffer-size into account when making
the decision about whether or not to continue reading?
Something along those lines:
(or (pos? size)
(and (= 0 size)
(pos? buffer-size)))
Am Montag, 26. August 2019 07:01:01 UTC+2 schrieb Andy Fingerhut:
>
> Ah, I should have read further in the Java doc here, though, before
> posting. In particular, the last sentence of this paragraph: "If the
> length of b is zero, then no bytes are read and 0 is returned; otherwise,
> there is an attempt to read at least one byte. If no byte is available
> because the stream is at the end of the file, the value -1 is returned;
> otherwise, at least one byte is read and stored into b."
>
>
> https://docs.oracle.com/javase/8/docs/api/java/io/InputStream.html#read-byte:A-
>
> If implementations actually follow that documentation, then it appears
> that a non-0 buffer size should never result in a return value of 0.
>
> Andy
>
> On Sun, Aug 25, 2019 at 9:54 PM Andy Fingerhut <[email protected]
> <javascript:>> wrote:
>
>> That bit of Java-Doc says nothing about the behavior when providing a
>> buffer b with a non-0 length.
>>
>> If it said: "If the length of b is non-zero, then the return value will
>> never be 0", then I might agree with you. Also, if you knew for some
>> reason that the implementation guaranteed this. (I have not looked at the
>> implementation to know either way.)
>>
>> Andy
>>
>> On Sun, Aug 25, 2019 at 9:21 PM 'Dirk Wetzel' via Clojure <
>> [email protected] <javascript:>> wrote:
>>
>>> As alpeware already said, *.read* will not return [1024, 0, 1024, 201,
>>> -1] because it will not return a zero unless *buffer-size* is zero.
>>> This bit of the Java-Doc: If the length of b is zero, then no bytes are
>>> read and 0 is returned;
>>>
>>> So if the check is changed to (<= 0 size), passing a *buffer-size* of 0
>>> (for whatever silly reason) would result in an infinite loop.
>>> While not my decision to make, I personally don't think that this would
>>> be desirable behaviour.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to [email protected]
>>> <javascript:>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> [email protected] <javascript:>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected] <javascript:>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/clojure/9deb8024-ce4b-4ef4-88d0-bbd817152ab6%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/clojure/9deb8024-ce4b-4ef4-88d0-bbd817152ab6%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/c6674761-8e16-4cc7-8b46-ab18aa7911f2%40googlegroups.com.
