Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!gargoyle!oddjob!mimsy!chris From: chris@mimsy.UUCP Newsgroups: comp.lang.c,comp.unix.wizards Subject: Re: Network Software Bug Message-ID: <9525@mimsy.UUCP> Date: Wed, 25-Nov-87 10:37:25 EST Article-I.D.: mimsy.9525 Posted: Wed Nov 25 10:37:25 1987 Date-Received: Sun, 29-Nov-87 03:11:00 EST References: <126@telesoft.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 36 Keywords: SunOS, 3.4, /etc/group Xref: utgpu comp.lang.c:5286 comp.unix.wizards:5233 In article <126@telesoft.UUCP> souza@telesoft.UUCP (Steve Souza @eldest) writes: > FILE *pp; > char buf[BUFSIZ]; > ... > while (fgets(buf, BUFSIZ, pp) != NULL) > if (write(s, buf, BUFSIZ) < 0) { > pclose(pp); > return(1<<8); > } > char obuf[BUFSIZ]; > > while (1) { > if (read(sock, obuf, BUFSIZ) > 0) > write(1, obuf, strlen(obuf)); > else > break; > } 0. fgets gets a NUL-terminated string, which may be < BUFSIZ bytes. Writing BUFSIZ bytes down `s' writes whatever other trash is in buf[]. 1. read returns a byte count, which you ignore. It does not guarantee that obuf will be NUL-terminated, yet you call strlen on obuf. 2. There is no guarantee that the read(sock) will always read exactly as many bytes as the write(s) wrote. It could read fewer; it could read more (although in this case it cannot, since writer writes BUFSIZ and reader reads BUFSIZ). 3. You neither check nor cast to void the return value from write(1). Clearly you have not used lint. Four bugs in 15 lines of code ... not bad. (Well, there were more lines in the original posting, but they had more bugs too.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris