What's the proper use of printf to display pointers padded with 0s
Solution 1:
#include <inttypes.h>
#include <stdint.h>
printf("%016" PRIxPTR "\n", (uintptr_t)ptr);
but it won't print the pointer in the implementation defined way (says DEAD:BEEF
for 8086 segmented mode).
Solution 2:
Use:
#include <inttypes.h>
printf("0x%016" PRIXPTR "\n", (uintptr_t) pointer);
Or use another variant of the macros from that header.
Also note that some implementations of printf()
print a '0x
' in front of the pointer; others do not (and both are correct according to the C standard).
Solution 3:
This answer is similar to the one given earlier in https://stackoverflow.com/a/1255185/1905491 but also takes the possible widths into account (as outlined by https://stackoverflow.com/a/6904396/1905491 which I did not recognize until my answer was rendered below it ;). The following snipped will print pointers as 8 0-passed hex characters on sane* machines where they can be represented by 32 bits, 16 on 64b and 4 on 16b systems.
#include <inttypes.h>
#define PRIxPTR_WIDTH ((int)(sizeof(uintptr_t)*2))
printf("0x%0*" PRIxPTR, PRIxPTR_WIDTH, (uintptr_t)pointer);
Note the usage of the asterisk character to fetch the width by the next argument, which is in C99 (probably before?), but which is quite seldom seen "in the wild". This is way better than using the p
conversion because the latter is implementation-defined.
* The standard allows uintptr_t
to be larger than the minimum, but I assume there is no implementation that does not use the minimum.
Solution 4:
The only portable way to print pointer values is to use the "%p"
specifier, which produces implementation-defined output. (Converting to uintptr_t
and using PRIxPTR
is likely to work, but (a) uintptr_t
was introduced in C99, so some compilers may not support it, and (b) it's not guaranteed to exist even in C99 (there might not be an integer type big enough to hold all possible pointer values.
So use "%p"
with sprintf()
(or snprintf()
, if you have it) to print to a string, and then print the string padding with leading blanks.
One problem is that there's no really good way to determine the maximum length of the string produced by "%p"
.
This is admittedly inconvenient (though of course you can wrap it in a function). If you don't need 100% portability, I've never used a system were casting the pointer to unsigned long
and printing the result using "0x%16lx"
wouldn't work. [UPDATE: Yes, I have. 64-bit Windows has 64-bit pointers and 32-bit unsigned long
.] (Or you can use "0x%*lx"
and compute the width, probably something like sizeof (void*) * 2
. If you're really paranoid, you can account for systems where CHAR_BIT > 8
, so you'll get more than 2 hex digits per byte.)