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