Must casting destroy lvalueness?

Bob Larson blarson at usc-oberon.UUCP
Sun Oct 26 00:15:44 AEST 1986


In article <55 at cartan.Berkeley.EDU> desj at brahms (David desJardins) writes:

[some stuff so wrong that I decided to reply]

>In article <4617 at brl-smoke.ARPA>, NET-RELAY.ARPA>@brl-smoke.ARPA writes:
>>                     For example, a useful and readable way to move a pointer 
>> through a buffer containing a mixture of objects of different sizes is 
>>
>>                        ((OBJECT)pointer)++

Here is a major misconseption, based on a limited set of machines and a
limited imagination:
>   But the point is that casts of pointers *don't* convert.  

Repeat until remembered:

	CASTS DO ANY NESSISARY CONVERSION.

There are machines with more than one type of pointer.  C makes no
assuptions that require there only to be one type of pointer.
"Byte" pointers on a PDP-10 include both the bit position and size of
the object being pointed to.  There are quite a few machines with
different "word" and "character" pointers.

To do what the original poster wanted (as portably as possible):

	(pointer = (type_of_pointer) ((char *)pointer + sizeof(OBJECT)))

It says what you mean.  It is no more ugly than what you are trying to
do.  The explicit casts are obvious places to look for portablility
problems.  

[ If casts did not implicitly lose the lvalueness of the expression,
can you tell me what the following code fragment should do? Please
explain in terms the begining C programer who meant f += (float)i;
could understand, as well as the non-portable C coder who means 
*(int *)&f = i;

	float f = 0.1;
	int i = 2;
	(int)f += i;
]
-- 
Bob Larson
Arpa: Blarson at Usc-Eclb.Arpa	or	blarson at usc-oberon.arpa
Uucp: (ihnp4,hplabs,tektronix)!sdcrdcf!usc-oberon!blarson



More information about the Comp.lang.c mailing list