Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site bbncc5.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!bbnccv!bbncc5!keesan
From: keesan@bbncc5.UUCP (Morris M. Keesan)
Newsgroups: net.lang.c
Subject: Re: type cast in initializer
Message-ID: <1450@bbncc5.UUCP>
Date: Fri, 31-Jan-86 15:18:30 EST
Article-I.D.: bbncc5.1450
Posted: Fri Jan 31 15:18:30 1986
Date-Received: Sat, 1-Feb-86 20:34:24 EST
References: <302@hsi.UUCP>
Reply-To: keesan@bbncc5.UUCP (Morris M. Keesan)
Organization: Bolt Beranek and Newman, Cambridge, MA
Lines: 35

In article <302@hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>I've found the two lines
>
>	int	x = 0;
>	char	*ptr = (char *) &x;
>
>acceptable to every C compiler I've used, until running into the
>Whitesmith's C compiler.  They refuse to accept the type coercion "(char *)"
>on the second initialization.  As I read K&R this should be acceptable
>through the rules
>
>	initializer:
>		= expression			(Sec. 8.6)
>
>	expression:
>		( type-name ) expression	(Sec. 7.2)
>
>I talked to Whitesmiths about this and they are firm that their
>interpretation of the "standard" is that a type coercion following the
>equals sign is not allowed and they don't plan to change their compiler.

    My interpretation agrees with yours.  Whitesmith are going by section 15,
which enumerates the operators which are allowed in a constant expression,
type-casting not being one of them.  They are missing the additional information
in paragraph 2 of 8.6, which increases the sorts of expression allowed, in
particular allowing automatic variables to be initialized by "arbitrary
expressions involving constants, and previously declared variables and
functions."  

    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.  
-- 
Morris M. Keesan
keesan@bbn-unix.ARPA
{decvax,ihnp4,etc.}!bbncca!keesan