Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!seismo!cmcl2!yale!husc6!mit-eddie!genrad!decvax!tektronix!uw-beaver!tikal!sigma!uw-nsr!john
From: john@uw-nsr.UUCP
Newsgroups: comp.arch
Subject: Re: catering to bad code
Message-ID: <955@uw-nsr.UUCP>
Date: Fri, 27-Feb-87 14:59:31 EST
Article-I.D.: uw-nsr.955
Posted: Fri Feb 27 14:59:31 1987
Date-Received: Sun, 1-Mar-87 15:34:43 EST
References: <14833@amdcad.UUCP> <28200009@ccvaxa>
Reply-To: john@uw-nsr.UUCP (John Sambrook 5-7433)
Followup-To: comp.lang.c
Organization: UW-Bioengineering, Seattle, WA
Lines: 55
Summary: Clarification of "pointer problems"

In article <28200009@ccvaxa> wombat@ccvaxa.UUCP writes:
>
>/* Written 11:33 pm  Feb 19, 1987 by john@uw-nsr.UUCP in ccvaxa:comp.arch */
>At any rate it has been my experience that something like 70 - 80 %
>of the C programs I have ported have had pointer problems.
>/* End of text from ccvaxa:comp.arch */
>
>Grepping through the Gould UTX 2.0 sources, I found 19 standard 4.3BSD
>progams (out of about 420) had been altered so as to survive in the
>crash-'em-on-null-pointer-dereferences environment. Or rather, that's
>how many had the change commented, and any change to user-level code is
>supposed to be commented.

There are a couple of factors here that I feel need to be taken into
account.  Sorry that I did not make them clear in my first posting.
I would also like to thank "wombat" for pointing out where I was not
clear.
	
First, the code that I was talking about when I said 70 - 80 % had 
pointer problems was not the code from 4.3BSD.  Rather, it was the 
standard assortment of C code posted to mod.sources and net.sources
over the last year or so.  Owing to its relative newness this code 
is naturally less well tested than the code in 4.3BSD.

Second, when I say "pointer problems" I was not restricting my figures
to programs that dereference through null, though certainly a large 
number of programs do this.  An equally serious problem from my 
perspective is that a number of programs do something like this:

	typedef struct _mumble 
	{
		int foo;
		char bar;
	} mumble;

	f()
	{
		mumble	m;
		int	fd;

		if (read(fd, &m, sizeof(m)) == -1)
			.	
			.    
			.
	}

Everyone sees the (hopefully only one) bug in this code, right?

I suppose that this is getting away from the charter for this newsgroup.
I have directed follow-ups to comp.lang.c, where I suspect the bulk of
the readership is thoroughly bored with this topic.  I know I am :-)

-- 
John Sambrook                           Work: (206) 545-7433
University of Washington WD-12          Home: (206) 487-0180
Seattle, Washington  98195              UUCP: uw-beaver!uw-nsr!john