Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.UUCP
Newsgroups: comp.lang.c,news.software.b
Subject: Re: passing NULL to functions
Message-ID: <468@haddock.UUCP>
Date: Thu, 30-Apr-87 12:16:57 EDT
Article-I.D.: haddock.468
Posted: Thu Apr 30 12:16:57 1987
Date-Received: Fri, 1-May-87 04:29:58 EDT
References: <150@sds.UUCP>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 24
Xref: utgpu comp.lang.c:1909 news.software.b:548

In article <150@sds.UUCP> dave@sds.UUCP (dave schmidt x194) writes:
>I agree; the problem is compounded by the fact that certain C library
>routines encourage this sort of thinking.  For example, the MicroSoft
>Xenix manual says of time(): "long time(tloc) long *tloc; ... If 'tloc'
>(taken as an integer) is nonzero, the return value is also stored in the
>location to which 'tloc' points."  [...] I assume the manual means "... if
>'tloc' (taken as an integer of the requisite size) is nonzero, ..."

Neither phrasing is correct.  A pointer variable which contains a null pointer
need not result in zero if cast back to an arithmetic value.

>Worse yet, consider what the manual says about tmpnam():
>"char *tmpnam(s) char *s; ... If 's' is NULL, ...  If 's' is not NULL ..."
>This CLEARLY implies that "tmpnam(NULL)" is CORRECT, which it is ***NOT***.

I think the phrasing here is better than above, although "a null pointer" or
"(char *)0" or "(char *)NULL" might be better still (to eliminate the "clear
implication" you find).  I don't believe your inference, btw; I think it
clearly implies that the code will be testing the value with the equivalent of
"if (s == NULL) ...", which is perfectly correct.  It's unfortunate that the
cast is required, and that the user has to already know that; but (until ANSI)
them's the rules.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint