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