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