Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!rlgvax!hadron!jsdy
From: jsdy@hadron.UUCP (Joseph S. D. Yao)
Newsgroups: net.lang.c
Subject: Re: type cast in initializer
Message-ID: <232@hadron.UUCP>
Date: Sat, 1-Feb-86 11:35:30 EST
Article-I.D.: hadron.232
Posted: Sat Feb  1 11:35:30 1986
Date-Received: Wed, 5-Feb-86 05:07:34 EST
References: <302@hsi.UUCP> <1450@bbncc5.UUCP>
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Lines: 21
Summary: why cast?  two reasons.

In article <1450@bbncc5.UUCP> keesan@bbncc5.UUCP (Morris M. Keesan) writes:
>In article <302@hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>>	int	x = 0;
>>	char	*ptr = (char *) &x;
>    In any case, I'm not sure why you'd want to do what your example does,
>since the cast here is a no-op.  

Two reasons are immediately obvious.  The less compelling is that
lint tells you to.  The more compelling is that on some computer
architectures, e.g. one with type-tagged pointers, the cast may
[ NOTE:  n o t  "will", just "may" ] not be a no-op.  Some compilers
will even reject the un-cast initialisation out of hand.

Come to think of it, the 'lint' reason is not less compelling.
Since you are doing something "unnatural" -- pointing to an object
of one type with a pointer of another type -- this falls under the
heading of explicitly having to say, "yes, this is not an error, I
do mean to do exactly what this says."
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}