Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!styx!ptsfa!ihnp4!homxb!houxm!mtuxo!pegasus!hansen
From: hansen@pegasus.UUCP
Newsgroups: comp.lang.c
Subject: Re: NULL pointers as arguments
Message-ID: <2975@pegasus.UUCP>
Date: Wed, 29-Apr-87 15:24:07 EDT
Article-I.D.: pegasus.2975
Posted: Wed Apr 29 15:24:07 1987
Date-Received: Sat, 2-May-87 03:08:52 EDT
References: <1130@ius2.cs.cmu.edu>
Reply-To: hansen@pegasus.UUCP (60021254-Tony L. Hansen;LZ 3B-315;6243)
Distribution: na
Organization: AT&T-IS Labs, Lincroft, NJ
Lines: 32
Keywords: NULL, pointers, C
Summary: I like this idea

<  It seems to me that the problems of having foo(NULL) be correct on
< whatever machine you are working on could be taken care of by 
< having pointer arguements aways be type coerced into whatever the
< largest pointer type is on the machine (in cases presented to
< me that is char *).  This could be done as part of the language
< definition just as the float parameter are typed coerced into
< doubles.  This assumes there is some bound on pointer type sizes
< though.  Any comments?
<					Eddie Wyatt

Given that this were only done when no function prototype is in scope, this
simple suggestion would solve so many problems that it seems silly that it
wasn't suggested a LONG type ago. Treat the multitude of pointer types the
same way that the multitude of integer and floating types are treated. As
MOST functions will have prototypes defined, and most of the varargs
functions which cannot have prototypes defined usually don't pass more than
characte pointers around, there should be no efficiency problems with this
idea.

Given this idea, the only correct type for NULL would be "(void*)0", so that
it too could be correctly coerced, if necessary.  Would there be any
troubles casting pointers to functions? I can't think of anything else which
might cause troubles.

I don't have my dpANS copy handy, so I can't think of anything in there
which would preclude this concept.  It even seems to be ALLOWABLE under the
current dpANS definition.

Can anyone else find any flies in this idea?

					Tony Hansen
					ihnp4!pegasus!hansen