Ah, if only git existed when that comment was written! :-D
This comment is indeed pretty old. It was already present
in the Second Edition.
--
David du Colombier
2015-08-12 9:25 GMT+02:00 David du Colombier 0in...@gmail.com:
This comment is indeed pretty old. It was already present
in the Second Edition.
So that check is based on pre 9p2000 code? If so, Charles have probably
explained it:
2015-08-10 17:40 GMT+02:00 Charles Forsyth
On 12 August 2015 at 10:18, Giacomo Tesio giac...@tesio.it wrote:
So, seem that ignoring zeros is simply wrong. A residual from the past...
There doesn't seem to be any justification for it now, whatever the
original problem.
Even if there were something, I'd fix that instead of ignoring the
2015-08-11 17:48 GMT+02:00 Charles Forsyth charles.fors...@gmail.com:
On 10 August 2015 at 15:11, Giacomo Tesio giac...@tesio.it wrote:
/*
* reading from a pipe or a network device
* will give an error after a few eof reads.
* however, we cannot tell the difference
* between a
As a further historical note, originally 9P required a stream that preseved
record boundaries, and the reliable datagram protocol IL/IP and pipes did
that. Once TCP/IP was used, there was some fussing needed to work out where
the records were, so the revision 9P2000 added a size and the stream
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
2015-08-10 16:54 GMT+02:00 Charles Forsyth charles.fors...@gmail.com:
Zero conventionally means end-of-file, but record boundaries are preserved
on capable streams, so if a writer writes zero, the reader reads zero.
However this two requirements do not seem reconcilable.
Zero can either mean
On 10 August 2015 at 21:17, Giacomo Tesio giac...@tesio.it wrote:
Zero can either mean EOF or I'm alive but boring.
I can't see how a reliable communication (a cpu connection for example) can
survive this mismatch.
I'm probably missing something.
A specialised reader and writer can always
Hi, I've a probably naive question that I can't figure out.
I've just noticed that fcall(2) states
Read9pmsg calls read(2) multiple times, if necessary, to
read an entire 9P message into buf. The return value is 0
for end of file, or -1 for error; it does not return partial
messages.
but
on plan 9 systems 0 writes are not discarded.
- erik
On Aug 10, 2015 7:11 AM, Giacomo Tesio giac...@tesio.it wrote:Hi, Ive a probably naive question that I cant figure out.Ive just noticed that fcall(2) statesRead9pmsg calls read(2) multiple times, if necessary, to
read an entire 9P message into
10 matches
Mail list logo
