Why should we not rely on #atEnd?

Citing from
https://pharo.fogbugz.com/f/cases/21577/Cannot-read-from-dev-urandom,

   But we still shouldn't be relying on #atEnd so ... -- Alistair Grant

Why should we not rely on #atEnd? I had the impression that it is one of
the most fundamental stream APIs, alongside next, nextPut: and reset.

Herby

Hi herbert

I did not read the issue but I imagine that it may be linked to the
fact that it raises an exception or not.
Now streams can also be infinite so atEnd: for them is always false.

Stef

On Mon, Mar 26, 2018 at 6:51 PM, Herbert Vojčík <[hidden email]> wrote:

reading the bug entry is worth
Thanks for posting it.

Stef


On Mon, Mar 26, 2018 at 8:04 PM, Stephane Ducasse
<[hidden email]> wrote:

Hi Herby,

On 26 March 2018 at 18:51, Herbert Vojčík <[hidden email]> wrote:
The short answer is: because the underlying libraries we rely on say not
to.

For regular files, the VM compares the current file position to the
length of the file to determine whether the stream is at the end of the
file.

This works for files where the length is known in advance, but fails for
other files, e.g. /dev/urandom, which returns a size of 0, so #atEnd
currently and incorrectly returns true.

For stdio streams the VM falls back to using the C feof() function.  The
documentation states that it should only be used to determine if the end
of file was reached after reading past the end of the file.

A longer description is at:

https://stackoverflow.com/questions/12337614/how-feof-works-in-c:

I've proposed a patch to the VM that will result in feof() being used
for non-regular files like /dev/urandom, which would mean that #atEnd
answers correctly.  But #atEnd still shouldn't be used as a test while
looping over streams.


HTH,
Alistair