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 <herby@mailbox.sk> wrote:

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 Herby, On 26 March 2018 at 18:51, Herbert Vojčík <herby@mailbox.sk> wrote:

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

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