type cast in initializer
Joseph S. D. Yao
jsdy at hadron.UUCP
Tue Feb 11 03:22:44 AEST 1986
In article <1100 at lsuc.UUCP> msb at lsuc.UUCP (Mark Brader) writes:
>In regard to...
>> > > 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.
>Joseph S. D. Yao responds...
>> Two reasons are immediately obvious...
>
>and goes on to give three reasons. Two are excellent, but the other is wrong:
>> ... 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.
(and this was the non-obvious, third reason.)
>If this is not a slip, it stems from a misconception of casting which
>is a Frequently Repeated Error in this newsgroup. ...
>The cast specifies a conversion. ...
>In the case of type-tagged pointers, the cast specifies that the
>pointer tagged "int" is to be converted to one tagged "char" and
>stored in the variable, but so would the initialization or assignment
>without the cast, if the compiler accepts it at all.
Perhaps this is my mistake, but I don't see what you have said that
differs from mine. Yes, it specifies a conversion (if necessary).
Therefore the cast may possibly not be a no-op. As you note, to
even compile with some compilers, it may be required. Even if it
is not required, however, then it is implicit and (possibly) not a
no-op. The fact that it is required to be explicit on some machines
and not cared about on others implies that you should use it if you
desire that your code be more "portable". Does this explain why I
say that it may not be a no-op?
--
Joe Yao hadron!jsdy at seismo.{CSS.GOV,ARPA,UUCP}
More information about the Comp.lang.c
mailing list