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 stre
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
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
The read method returns the number of bytes consumed from the input stream
and stored in the provided buffer.
The only case the read method would return 0 is when a buffer of length 0
is provided since there would be no place to store any bytes consumed from
the input stream.
In most cases, a
I posted this also to ask.clojure.org forum at
https://ask.clojure.org/index.php/8450/strange-behavior-with-clojure-java-io-copy
On Sunday, August 25, 2019 at 8:05:57 PM UTC+3, Juha Syrjälä wrote:
>
> Hi,
>
> I found a strange behavior in implementation of clojure.java.io/copy
> function
>
>
> h
Hi,
I found a strange behavior in implementation of clojure.java.io/copy
function
https://github.com/clojure/clojure/blob/ee1b606ad066ac8df2efd4a6b8d0d365c206f5bf/src/clj/clojure/java/io.clj#L391
(defn copy
"Copies input to output. Returns nil or throws IOException.
Input may be an InputStr
