On Tue, Sep 2, 2008 at 11:31 AM, Jesus Cea <jcea@jcea.es> wrote:
Isaac Morland wrote:
On Tue, 2 Sep 2008, Jesus Cea wrote:
Indeed. read(0) is quite often generated as an edge case when one is computing buffer sizes, and returning an empty string is most definitely the right thing to do here (otherwise some application code becomes more complex by having to avoid calling read(0) at all).
How do you differenciate between that empty string (when doing "read(0)"), from EOF (that is signaled by an empty string)?.
Why would you expect a difference between reading 0 bytes at EOF and reading 0 bytes anywhere else? If you read(4) when at offset 996 in a 1000-byte file I doubt you expect any special notification that you are now at EOF.
My message was an answer to Guido one, saying that some programs calculate the read len substracting buffer lengths, so, then can try to read 0 bytes. Guido argues that returning a empty string is the way to go.
My point is: we are simplifying the program considering "0" a valid len counter, but we complicates it because now the code can't consider "" = EOF if it actually asked for 0 bytes.
Note that it has been like this for a very long time.
The Unix read() system call doesn't treat EOF as special other than it won't return bytes from "beyond" EOF and therefore even when reading a regular file could return fewer (including 0) bytes than asked for in the call.
I always consider ""==EOF. I thought that was correct for non-blocking sockets. Am I wrong?.
You can continue to assume this if you never pass 0 to read(). -- --Guido van Rossum (home page: http://www.python.org/~guido/)