Topic: Converting pointers to integral types
Author: Jeff Brown <Jeff_Brown@Intuit.com>
Date: 2000/01/25 Raw View
I'm dealing with some legacy code that converts a void* to short. Yeah,
I know it's ugly, (I said it was legacy code), but it works because a
short is what the void* got set to in the first place. Imagine the code
to be equivalent to:
void* p;
short s;
p = s;
...
s = (short)p;
This compiled without complaint on MSVC 6 and CodeWarrior Pro 4. Now
I'm compiling it with a Sun compiler, and it complains. So, I tried to
figure out what the ISO standard says about converting pointers to
integral types. It appears to me to make no statement at all about
implicit or explicit conversion of a pointer to an integral type, hence
implying that it is illegal (which is what the Sun compiler is telling
me). However, the Sun compiler allows:
long l = (long)p;
so either the Sun compiler is wrong, or the standard allows some
pointer-to-integral conversions.
My question is: what are the rules for pointer-to-integral conversions,
and what section of the standard can they be found in?
BTW, I know the right thing to do would be to rewrite the whole mess,
but for a variety of reasons that won't happen. I know I could solve my
immediate problem with:
s = static_cast<short>(reinterpret_cast<long>(p));
but I'm not entirely happy with that because it assumes
sizeof(long)==sizeof(void*), and for all I know, the reinterpret_cast
could be illegal.
If it is legal to cast a pointer to an integral type, is there a type
guaranteed to be appropriate? I don't believe that long, size_t, or
even ptrdiff_t are guaranteed to be the same size as void*. Also, would
a static_cast work (or be better) than a reinterpret_cast?
Jeff Brown
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jim Cobban <thesnaguy@hotmail.com>
Date: 2000/01/25 Raw View
This is a multi-part message in MIME format.
--Boundary_(ID_rYLe+g8HSClgpY0fxYuszA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE
Jeff Brown wrote:
> I'm dealing with some legacy code that converts a void* to short. =
Yeah,
> I know it's ugly, (I said it was legacy code), but it works because=
a
> short is what the void* got set to in the first place. Imagine the=
code
> to be equivalent to:
>
> void* p;
> short s;
> p =3D s;
> ...
> s =3D (short)p;
>
> This compiled without complaint on MSVC 6 and CodeWarrior Pro 4. N=
ow
> I'm compiling it with a Sun compiler, and it complains. So, I trie=
d to
> figure out what the ISO standard says about converting pointers to
> integral types. It appears to me to make no statement at all about
> implicit or explicit conversion of a pointer to an integral type,
The statement you are looking for is in section 5.2.10 paragraphs 4 a=
nd 5
which state:
"A pointer can be explicitly converted to any integral type large eno=
ugh to
hold it. The mapping function is implementation-defined [Note: it is =
intended
to be unsurprising to those who know the addressing structure of the
underlying machine.]
A value of integral type or enumeration type can be explicitly conver=
ted to a
pointer. A pointer converted to an integer of sufficient size (if any=
such
exists on the implementation) and back to the same pointer type will =
have its
original value; mappings between pointers and integers are otherwise
implementation=ADdefined."
Then section 5.4 defines the old C cast mechanism in terms of the new=
C++
casts. Some compiler manufacturers have left the old implementation =
in
place, which doesn't check for whether there are enough bits in the t=
arget
integer, but it is part of the philosophy of C++ that it should flag =
as many
obvious programming risks as possible.
Now back in the days of DOS on PCs there was a small application mode=
l,
typically used by .COM programs, in which the entire program and its =
data fit
into a single 64K byte page. In this situation "near" pointers could=
be used
which were only 16 bits long and therefore their value would fit in a=
short.
It is difficult to see why you would want to retain a short for this =
purpose.
--
Jim Cobban jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438
--Boundary_(ID_rYLe+g8HSClgpY0fxYuszA)
Content-type: text/x-vcard; charset=us-ascii; name=thesnaguy.vcf
Content-description: Card for Jim Cobban
Content-disposition: attachment; filename=thesnaguy.vcf
Content-transfer-encoding: QUOTED-PRINTABLE
begin:vcard=20
n:Cobban;James
tel;fax:+1-613-592-9438
tel;home:+1-613-592-9438
x-mozilla-html:FALSE
url:http://www.magma.ca/~jcobban
version:2.1
email;internet:thesnaguy@hotmail.com
title:Consultant
adr;quoted-printable:;;34 Palomino Dr.=3D0D=3D0A;Kanata;ON;K2M 1M1;Ca=
nada
fn:Jim Cobban
end:vcard
--Boundary_(ID_rYLe+g8HSClgpY0fxYuszA)--
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david@tribble.com>
Date: 2000/01/27 Raw View
Jeff Brown wrote:
>> I'm dealing with some legacy code that converts a void* to short.
>> Yeah, I know it's ugly, (I said it was legacy code), but it works
>> because a short is what the void* got set to in the first place.
>> Imagine the code to be equivalent to:
>>
>> void* p;
>> short s;
>> p = s;
>> ...
>> s = (short)p;
Jim Cobban wrote:
> It is difficult to see why you would want to retain a short for
> this purpose.
Indeed, a better strategy would be to convert the pointer into an
index, by scaling it (dividing it) by the size of the object(s)
you are concerned with; the result would probably fit into a short
very easily.
-- David R. Tribble, david@tribble.com, http://david.tribble.com --
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]