Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!sunybcs!ugkamins
From: ugkamins@sunybcs.uucp (John Kaminski)
Newsgroups: comp.os.minix
Subject: Re: /usr/minix/amoeba/examples/client3.c
Message-ID: <4883@cs.Buffalo.EDU>
Date: 24 Mar 89 00:24:46 GMT
References: <11077@louie.udel.EDU> <27232@cci632.UUCP>
Sender: nobody@cs.Buffalo.EDU
Reply-To: ugkamins@sunybcs.UUCP (John Kaminski)
Organization: SUNY/Buffalo Computer Science
Lines: 28

In article <27232@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes:
>>which is of the form  "if ((n=read(fd,buf,bytes) < 0))" and, as stated
>>on page 15 of K&R, this always sets n to 0 or 1, rather than the number
>>of bytes read.
>
>The code is correct.  If there is an error with the read, it returns -1.
>Check page 160, K&R, section 8.2 (Low Level I/O - Read and Write), the second
>paragraph (the one that begins "Each call returns..." - the paragraph after
>the sample code).
>
>Thomas V. Frauenhofer	...!rutgers!rochester!cci632!ccird7!tvf
>*or* ...!rochester!cci632!ccird7!frau!tvf *or* ...!rochester!rit!anna!ma!tvf1477




The beef is not in what read() returns, but in the ordering of the paren.
The trouble arises out of wishing to set "n" to the result of the read().
As per the article above, one set of paren's is superfluous, since the "if"
doesn't require paren's inside its paren's, and the expression would eval
just fine w/o enclosing it in paren's.  What most people would say is that the
paren. just b4 the one for the end of the "if" should instead be after the
closing one for the read().    
That would set "n" to the result of the read() and then pass the "value" of that
assignment along to the comparison part.  As it is, the result of the read is
sent along to the comparison, and then the result of the comparison (0 or 1)
is then assigned to "n."  The relavent (sp?) part of K&R to consult is that
which deals with precedence of operators in expressions.