pointers, tests, casts

[Chris Torek]

>In article <9038 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
>writes:
>>True of pre-ANSI C, but an ANSI C implementation can use either
[#define NULL 0] or
>>#define NULL ((void*)0)
>>I recommend the former even for ANSI C implementations. ...

In article <44803 at yale-celray.yale.UUCP> wald-david at CS.YALE.EDU
(david wald) writes:
>I may be sorry in the morning for asking this, but:

Perhaps.

>Isn't the latter generally preferable,

Not particularly.

>given its possible use as a parameter for a function with no
>prototype in scope?

Unless that function takes a `void *' argument in that position, if
the NULL is uncast, the code remains incorrect.  The compiler cannot
diagnose this since the function might take a `void *' argument in that
position.  For instance:

	void **
	collect(void *first, ...) {
		va_list ap;
		int n;
		void **p, **q, *t;

		if (first) {
			va_start(ap, first);
			n = 2;
			while (va_arg(ap, void *) != NULL)
				n++;
			va_end(ap);
		} else
			n = 1;
		p = malloc(n * sizeof(void *));
		if (p == NULL)
			return (NULL);
		q = p;
		if (first) {
			*q++ = first;
			va_start(ap, first);
			while ((t = va_arg(ap, void *)) != NULL)
				*q++ = t;
		}
		*q = NULL;
		return (p);
	}

Collect() accepts only `void *'; the end of the list it is to collect
into a vector is marked by a nil `void *'.

(Incidentally, collect() is another example of why requiring an
`anchor' argument for va_start is bad.)

>Further, isn't the former dangerous in this case, given that there is
>no guarantee for NULL and (int)0 to have the same representation?

No more dangerous than the latter, given that there is no guarantee
for NULL and NULL (of two different types, e.g., `void *' nil and
`struct glorp *' nil) to have the same representation.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris