pointer -> long conversion
Morris Keesan
keesan at bbncca.ARPA
Wed Jul 18 00:50:47 AEST 1984
--------------------------------
>From: Travis Lee Winfrey <Us.Travis%CU20B at COLUMBIA-20.ARPA>
>
>Well, by "pure copy", I think that what they had in mind was a copy where
>information is neither lost (bits dropped) or irretrievably transmuted.
>So if I take a pointer and convert it to a long, I should be able to take
>that long variable containing the pointer, and convert it back to a usable
>pointer. If your compiler doesn't sign-extend, isn't it losing a bit of
>information?
Given pointers that are one word and longs that are two words, it actually
makes no difference in this scheme what goes into the high-order word. It
could be sign-extension, zero-fill, one-fill, or alternating ones and zeros.
In any case, converting it back to a pointer means taking the low-order word
and discarding the high-order word, so the high-order word contains absolutely
no information about the pointer that isn't in the low-order word.
-------------------------------------------------------------------------------
Although most of the votes on this issue seem to agree with my initial feeling
that sign-extension shouldn't be done, I've also seen enough votes the other
way, and enough agreement with my position that it doesn't matter, that I've
decided to leave the compiler alone.
If you thought that was fun, you'll love what the compiler does with equality
tests between a pointer and a long: it compares only the low-order word of the
long, ignoring the high order. I'm not even going to ask for opinions on this
one. It's incredibly ugly, anyone writing that kind of code is a fool, and I'm
hiding behind the "result is machine dependent" clause in the reference manual.
One last question -- does anyone know what the draft ANSI standard says about
all of this?
--
Morris M. Keesan
{decvax,linus,ihnp4,wivax,wjh12,ima}!bbncca!keesan
keesan @ BBN-UNIX.ARPA
More information about the Comp.lang.c
mailing list