Storing address: intptr_t vs uintptr_t

[cspace]

In using an integer to store a hex literal address, what is the difference between using intptr_t and uintptr_t? The reference indicates that they're both capable of holding a pointer value (http://en.cppreference.com/w/cpp/types/integer ).

In addition, I'm not sure what the following means " to that type with a value that compares equal to the original pointer" (http://www.cplusplus.com/reference/cstdint/ <- last entry of the "Types" table).

Thanks

[helios]

uintptr_t is unsiged and intptr_t is signed. There's no other difference.

The sentence means that if p is a valid pointer, then (void *)p == (void *)(uintptr_t)p and (void *)p == (void *)(intptr_t)p. In other words, any data pointer can be put in a (u)intptr_t and then retrieved without loss of information.

[cspace]

Would (u)intptr_t fall under the category of ints below?

quote: In theory, you could also use reinterpret_cast to cast pointers
to ints and ints to pointers, but this is considered erroneous programming,
because on many platforms (especially 64-bit platforms) pointers and ints are
of different sizes. For example, on a 64-bit platform, pointers are 64 bit, but
integers could be 32 bit. Casting a 64-bit pointer to a 32-bit integer will result in
losing 32 critical bits! [-found in "Professional C++ 3rd edition Marc Gregoire"-]

I sometimes see (u)intptr_t defined as "typedef (un)signed long (u)intptr_t", and since (un)signed long appears to be 32 bits, would it be proper to use (u)intptr_t in these cases?

In addition, I don't know what alternatives there are for storing hex literal address.

Thanks, and thanks for the earlier response as well

[helios]

Would (u)intptr_t fall under the category of ints below?

No, they're safe to cast to and from pointers. That's the point.

I sometimes see (u)intptr_t defined as "typedef (un)signed long (u)intptr_t", and since (un)signed long appears to be 32 bits, would it be proper to use (u)intptr_t in these cases?

However (u)intptr_t is defined, the only property that needs to be maintained is that casting a pointer to it and then back must preserve the value of the pointer. Any intrinsic type provided by the implementation that maintains this property may be used. For example, on MSVC targeting 32-bit Windows, the following types can be used for uintptr_t: unsigned int, unsigned long, unsigned __int32.

In addition, I don't know what alternatives there are for storing hex literal address.

Base is a property of a specific string of symbols. For example, "1083B99F34B59645" is a hexadecimal representation, and "102035631746455313105" is an octal representation. Both represent the same value: 1189998819991197253. Integers are values, not representations, so it doesn't make sense to talk about a hex integer.
I also don't know what you mean by "literal address". What would a non-literal address be?

[cspace]

I used "hex literal address" to mean the "literal" value here: (u)intptr_t anAddress = 0x1234'5678'90AB'CDEF;

It was my naive attempt to distinguish it from something like this:
(u)intptr_t anAddress = reinterpret_cast<(u)intptr_t>(&aLvalue);

Thanks very much for the details above