Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: comp.lang.c
Subject: Re: Casting NULL again
Message-ID: <4024@utcsri.UUCP>
Date: Wed, 28-Jan-87 12:12:42 EST
Article-I.D.: utcsri.4024
Posted: Wed Jan 28 12:12:42 1987
Date-Received: Wed, 28-Jan-87 23:47:42 EST
References: <3859@brl-adm.ARPA>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 29
Summary: 

In article <3859@brl-adm.ARPA> Peter@adm.UUCP writes:
>Thanks for your comments on this matter. Unfortunately, most
>of you misunderstood what I wanted. I realize that under some
>machines ints are 16 bits and pointers are 32. I have a MAC and
>thats the case there and I often have to pass parameters as
>(long)NULL to get the right number of bytes passed. That's
>nothing to do with pointers per se,=that's a "problem" of
???
If you are passing a long 0 to a function, you indeed should be casting
it to long:
	fseek( file, (long)0, 0 );

Or, use a long 0 constant:
	fseek( file, 0L, 0 );

but (long)NULL ? If you are using this to pass a 0L, then it is a misleading
use of the NULL symbol. If you are passing a NULL pointer and using a (long)
cast to make it the right size, you are making a mistake.

lint will tell you about this mistake; a function expects a pointer and is
being passed a long. There are machines where a long is not the same size as
a pointer, and there may well be machines where (long)0 does not give the
same bit pattern as a NULL pointer. If you are passing a NULL pointer
to a function expecting a (char *), just write (char *)NULL. Guaranteed to
work, no extra trouble, more self-explanatory.
-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...