Should we print pointers like glibc does?

[eyalroz]

glibc printf pointers like so: printf("%5p",(void *) 0x7b) gives you 0x7b. That is, no minimum width, no zero-padding by default, and with space-padding before the 0x. We do use a minimum width based on the size of pointers and we zero-pad (except for NULL). Should we switch to the way gcc does it?

[ls83tda]

I would prefer that "%p" prints unadorned hex (no "0x", no space or zero padding), and that "#" adds the "0x". Also, that it doesn't print "(nil)" for null pointers, just prints "0". i.e. format like "%x", for these reasons:

• Printing a table of pointers, "0x" in front of every entry is unwanted.
• On an 8-bit processor, it's perfectly feasible that some pointers will be in zero page, again particularly in a table "0x00ab" rather than "ab" amounts to unwanted cruft.
• In the standard, "#" is undefined when used with "%p", but since "%p" is implementation-specific anyway, it's reasonable to have it do something useful than be ignored.
• "(nil)" seems a strange and arbitrary thing to output (especially as "%s" prints "(null)") and anyway in this case there's no reason not to print "0". On a processor with 16-bit address space, printing "(nil)" means needing to allow for 5 characters for this special case, whereas everything else just needs 4 (assuming no "0x"). I know the current behaviour comes from glibc, but there these considerations aren't really relevant.

This was the approach taken in a commercial C compiler (Cosmic) I'm familiar with, and is I think more useful behaviour for an embedded environment.

[eyalroz]

Well, remember you can always print pointer values as though they were integers, and achieve whatever behavior you like. %p is a bit of a "vanity" feature. If we printed 0 instead of (nil) or (null), there really would be very little difference from %x.

The fact that the C library you suggest as an example of adoping this approach is a closed-source, less-common one, does not make for a compelling argument...

but this does beg the question of what considerations should guide on this matter:

• Compatibility with the most common C libraries (e.g. glibc)
• Number of users 'outspoken' about the matter in this direction or that
• The potential for code side reduction (that may actually encourage a-%X-like approach)
• The "aesthetical preferability" of the different approaches, although that is somewhat subjective.
• Something else?

anyway, I'm not making any such changes right away, so nothing is decided.

[ls83tda]

The key difference between "%x" and "%p" is that "%p" is guaranteed to correctly print a pointer. Integers and pointers may or may not be the same width. On the same codebase I happily use "%p" on 32-bit processors with 16-bit integers, 32-bit processors with 32-bit integers, as well as 8-bit processors with 16-bit integers. Without "%p" I have to use "%lx" along with casts, which results in real code bloat on the 8-bit, and it's still not portable to other configurations.

[eyalroz]

The key difference between "%x" and "%p" is that "%p" is guaranteed to correctly print a pointer. Without "%p" I have to use "%lx" along with casts, which results in real code bloat on the 8-bit, and it's still not portable to other configurations.

You're right that "%x" itself doesn't do the trick. But - you really wouldn't have to use casts, you would just need a portable preprocessor definition for your format specifier... and that is is already defined, actually: It's PRIxPTR (or PRIXPTR for upper-case); see here. It's in C99 and quite portable.