On Tue, Sep 2, 2008 at 11:31 AM, Jesus Cea <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
