jnall%FSU.BITNET@cunyvm.cuny.edu (John Nall 904-644-5241) (03/17/89)
I'm teaching a course in local networking this semester, using Andy's Second Edition networking book. Some of the students are having to learn C as they go, and I suggested the Kernighan and Ritchie "bible" as the best self-teaching text I know of. Therefore, I thought it was amusing that one of my students (a foreign student, actually, with a real language gap) who is just learning C pointed out to me that Andy's sample remote file client program, client3.c, does not work because the main routine has a read statement 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. John Nall Florida State University
tvf@cci632.UUCP (Tom Frauenhofer) (03/20/89)
In article <11077@louie.udel.EDU> jnall%FSU.BITNET@cunyvm.cuny.edu (John Nall 904-644-5241) writes: >Therefore, I thought it was amusing that one of my students (a foreign >student, actually, with a real language gap) who is just learning C >pointed out to me that Andy's sample remote file client program, >client3.c, does not work because the main routine has a read statement >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 BLOOM: You can't shoot the actors! They're human beings! BIALYSTOCK: Oh Yeah? You ever eat with one?
bryan@fafhrd.LBP.HARRIS.COM (Bryan Ivey (FAFHRD System Adminstrator)) (03/23/89)
In article <27232@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes: >In article <11077@louie.udel.EDU> jnall%FSU.BITNET@cunyvm.cuny.edu (John Nall 904-644-5241) writes: >>client3.c, does not work because the main routine has a read statement >>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 John Nall is making a reference to the levels of parenthesis, i.e., +--------------------------+ |+------------------------+| || +------------+ || || | | || if ((n=read(fd,buf,bytes) < 0)) should be +--------------------------+ |+--------------------+ | || +------------+| | || | || | if ((n=read(fd,buf,bytes)) < 0) Bryan Ivey Harris / Lanier Computer R & D Senior Systems Analyst 2310 Parklake Drive bryan@fafhrd.LBP.HARRIS.COM Atlanta, GA 30345
mat@emcard.UUCP (W Mat Waites) (03/23/89)
In article <27232@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes: >In article <11077@louie.udel.EDU> jnall%FSU.BITNET@cunyvm.cuny.edu (John Nall 904-644-5241) writes: >>pointed out to me that Andy's sample remote file client program, >>client3.c, does not work because the main routine has a read statement >>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 Sorry, but.... What a weenie! Did you _read_ page 15? How about page 215 where the priority of operators is explicitly listed? I think not! The original fragment: if ((n=read(fd,buf,bytes) < 0)) is equivalent to: if ((n=(read(fd,buf,bytes) < 0))) ^ ^ (new parens) not: if (((n=read(fd,buf,bytes)) < 0)) ^ ^ I assume the original author meant the second modification. It is this kind of instant, authoritative smelling, incorrect information that makes Usenet a poor information source for the uninitiated. Mat -- W Mat Waites | Oh, I used to be disgusted, but now I'm just amused. gatech!emcard!mat | Since their wings got rusted, you know the angels 8-5 ET: (404) 727-7197 | wanna wear my red shoes --E. Costello
tvf@cci632.UUCP (Tom Frauenhofer) (03/23/89)
In article <7501@galbp.LBP.HARRIS.COM> bryan@fafhrd.LBP.HARRIS.COM (Bryan Ivey (FAFHRD System Adminstrator)) writes: > >In article <27232@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes: >>In article <11077@louie.udel.EDU> jnall%FSU.BITNET@cunyvm.cuny.edu (John Nall 904-644-5241) writes: >>>client3.c, does not work because the main routine has a read statement >>>which is of the form "if ((n=read(fd,buf,bytes) < 0))" and, as stated >>The code is correct. <etc. on this point> >John Nall is making a reference to the levels of parenthesis, i.e., Yes, you're all right. It was, um, the glasses. Yeah! I forgot to wear my glasses. I had given them to my wife, um, Morgan Fairchild, yeah, that's the ticket... ( :-) ) Now, to stick my neck back into it, the code may not be "smart", but if you can assume that if n>0 then n==bytes, it should be okay. Of course, I do not think that a safe assumption. Thomas V. Frauenhofer ...!rutgers!rochester!cci632!ccird7!tvf *or* ...!rochester!cci632!ccird7!frau!tvf *or* ...!rochester!rit!anna!ma!tvf1477 BLOOM: You can't shoot the actors! They're human beings! BIALYSTOCK: Oh Yeah? You ever eat with one?
jnall%FSU.BITNET@cunyvm.cuny.edu (John Nall 904-644-5241) (03/23/89)
Responding to an earlier message of mine which pointed out that the
client3.c program has an error, Thomas V. Frauenhofer states that
> The code is correct.....
Well.....actually, it is not correct. You see, the "n" that the read
returns is assumed by the client3 program to be the number of bytes
which were remotely read. The program then proceeds on that basis.
It is quite easy to verify: Andy's networking works very well with both
the client and server on the same machine. Just do a make of server3
and client3, start server3 running, and type "client3 client3.c". It
will not list anything out (because the count of returned bytes is not
correct). Then go in and change the offending line to
have the correct nesting, and it does work. The proof of the pudding is
in the eating!
I agree it is a subtle error, though. That is why I thought it was so
neat that my beginning student caught it.ugkamins@sunybcs.uucp (John Kaminski) (03/24/89)
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.