"Richard Bos" <rlb@[EMAIL PROTECTED]
> wrote in message
news:48216449.1643908201@[EMAIL PROTECTED]
> Eric Sosman <esosman@[EMAIL PROTECTED]
> wrote:
>
>> C99 improves the situation, but only a little. If the integer
>> types intptr_t and uintptr_t exist, then any valid void* can be
>> converted to one of them and back again and survive the journey.
>> (There are no guarantees for invalid pointers, nor for converting
>> an arbitrary integer value to void* and back.) Note, though, that
>> these integer types are optional: If they exist they will work as
>> you desire, but on some "exotic" architecture they might be absent.
>
> On the upside, if your architecture is exotic enough that it has a C99
> implementation but no (u)intptr_t, it's probably not reliably possible
> to do this in the first place. So if including <stdint.h> doesn't result
> in a definition of UINTPTR_MAX, bailing out with an #error would
> probably have been your best option anyway.
>
> BTW, I still don't understand why we have both intptr_t and uintptr_t.
> We really only need either of those.
.... on any given system. I know of one system that defines pointers to
be
signed, so storing them in a signed integer type makes sense, particularly
if one wants to (non-****tably) manipulate them. On most other systems I'm
familiar with, pointers are unsigned, so you'd want to store them in an
unsigned integer type.
More practically speaking, I bet both exist simply because it's symmetric
and doesn't hurt. It also stops people from typing "unsigned intptr_t" if
that's what they want...
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible op****tunity." --Stephen Hawking
|
