Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP
Path: utzoo!watmath!kpmartin
From: kpmartin@watmath.UUCP (Kevin Martin)
Newsgroups: net.lang.c
Subject: Re: limitations of casts, pointer and function declarartions...
Message-ID: <9635@watmath.UUCP>
Date: Tue, 30-Oct-84 00:25:35 EST
Article-I.D.: watmath.9635
Posted: Tue Oct 30 00:25:35 1984
Date-Received: Tue, 30-Oct-84 01:35:54 EST
References: <120@harvard.ARPA> <5487@brl-tgr.ARPA> <122@harvard.ARPA>
Reply-To: kpmartin@watmath.UUCP (Kevin Martin)
Distribution: net
Organization: U of Waterloo, Ontario
Lines: 36


The correct method of doing a pointer to its own type or to something else
is:
	union x {
		union x *next;
		other_type pot_of_gold;
	};

Usins casts as you suggested is a sure way to get burned when you try
porting.

As for you comments about casting Lvalues, note that, even as Rvalues,
the expressions
	(int) x
and
	*(int *) &x
DO NOT DO THE SAME THING. The former takes 'x' and does a meaningful
(usually) conversion to int. The latter merely grabs the first 16 (or 32
or 36) bits of 'x' (regardless of its true size), and interprets the bit
pattern it found as an int.

Given the possibility of doing
	p = (char *)i;
I don't see any need for
	(char *)p = i;
no matter what interpretation you give to it. I find this statement it
no more sensical than, say,
	-x = y;
(after all, both the type cast and negation are valid unary operators)
Your argument about consistency with
	*(char *)&p = i;
is fallacious. The latter expression is indeed assigning to an Lvalue
(the result of the indirection operator), and is quite consistent with
other legal (and illegal) uses of type casting and the rules for L-
and R-values.
                      Kevin Martin, UofW Software Development Group.