Zero conventionally means end-of-file, but record boundaries are preserved on capable streams, so if a writer writes zero, the reader reads zero.
Having said that, I think the comment is wrong, and read9pmsg returning zero should be interpreted as the end of the (9p) stream. In most cases, the writer will be devmnt, locally or remote, and that should not be generating zero writes (empty records). Funnily enough, I was just going to ask about this myself, specifically whether anyone had seen this case, since I noticed yesterday than 9front had changed several read9pmsg calls to do the same thing, which I was curious about. After all, if an empty record is somehow commonly occurring in a 9p stream, and should be ignored, you'd think read9pmsg would be the place to do that. I don't, however, think anyone should be ignoring the zero return, and if something is generating spurious empty records, that writer should be fixed not to do it. On 10 August 2015 at 15:35, Giacomo Tesio <giac...@tesio.it> wrote: > 2015-08-10 16:22 GMT+02:00 erik quanstrom <quans...@quanstro.net>: > >> on plan 9 systems 0 writes are not discarded. >> > Interesting! Is this "by design"? > And what is the intended usage of 0 writes? > > BTW, so fcall(2) is misleading, a 0 read can not be used to identify an > EOF, right? > > > Giacomo >
