Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!amd!intelca!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.lang.c
Subject: Re: Passing (char *) NULL to printf to match %s
Message-ID: <25737@sun.uucp>
Date: Sun, 16-Aug-87 04:40:48 EDT
Article-I.D.: sun.25737
Posted: Sun Aug 16 04:40:48 1987
Date-Received: Sun, 16-Aug-87 22:15:20 EDT
References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP> <8416@utzoo.UUCP>
Sender: news@sun.uucp
Lines: 29

> > ...Sun's approach
> > of faulting gets bugs in programs detected much earlier in the
> > development cycle.  Printing "(null)" is roughly equivalent
> > to quietly mapping an out of bound subscript to zero...
> 
> It depends on what you are after.  For debugging work in particular, printing
> "(null)" is a significant convenience.  As for detecting bugs early... don't
> you *look* at the printed output?!?

Sun's approach of faulting when dereferencing a null pointer (which was, I
believe, not done to catch bugs, but was a conseqence of some UNIX
implementation on Suns - although the fact that dereferencing NULL in the
*kernel* on Sun-3s was, I believe, done to catch bugs, which it did) does
detect bugs in places other than "printf" calls, where looking at the output
may not help.

However, our "printf" doesn't dereference null pointers:

	gorodish$ cat foo.c
	main()
	{
		printf("%s\n", (char *)0);
	}
	gorodish$ cc foo.c
	gorodish$ ./a.out
	(null)
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com