Pointer formats, again...

[David Chase]

Based on discussions for the recent port-to-mavericks+clang/format-fun patch,
it appears that wrapping every pointer in p2i(...) before printing is ugly.  We'd like
to use %p, but cannot for customer-visible formatting because C++ was standardized
by a herd of cats.  We can't use PTR_FORMAT for this (at least not yet) both because
the change would be reasonably large, and because there are places where PTR_FORMAT
is used to express an intent in the source code, and that are also customer-visible.

Therefore, what we clearly need is ANOTHER FORMATTING MACRO.

It would be the equivalent of (done differently with conditional inclusion)

#if defined __GNUC__
#define PS_ PTR_FMT %p
#else
#define PS_PTR_FMT 0x%p
#endif

PS_PTR_FMT stands for Platform Specific PoinTeR ForMaT

I'm not the least bit attached to the name, PSPF would make me just as (un)happy.

This could not be used where the exact format of pointers matter, because
there is no width control, sometimes it might print "0xnull" (because C++ is Awe-Some)
and on windows it will print hex in uppercase.

Here's my test program:
#include <stdio.h>
int main(int argc, char ** argv) {
   printf("%%p of NULL='%p'\n", (void *) 0);
   printf("%%p of &main='%p'\n", &main);
   printf("%%4p='%4p'\n", argv);
   printf("%%16p='%16p'\n", argv);
   printf("%%016p='%016p'\n", argv);
   return 1;
}

Mountain Lion:
(compilation warnings for %016p)
%p of NULL='0x0'
%p of &main='0x105783e60'
%4p='0x7fff5a47c9d0'
%16p='  0x7fff5a47c9d0'
%016p='0x007fff5a47c9d0'

Ubuntu32, 13.10:
(compilation warnings for %016p)
%p of NULL='(nil)'
%p of &main='0x804841d'
%4p='0xbfacd584'
%16p='      0xbfacd584'
%016p='0x000000bfacd584'

Ubuntu64, 14.04:
(compilation warnings for %016p)
%p of NULL='(nil)'
%p of &main='0x40052d'
%4p='0x7fff573e68d8'
%16p='  0x7fff573e68d8'
%016p='0x007fff573e68d8'

Solaris11:
%p of NULL='0'
%p of &main='80509a0'
%4p='feffeac0'
%16p='        feffeac0'
%016p='00000000feffeac0'

I don't think we've got this to the point that I would call it a "good idea" yet.
It seems to me that we'd instead need to explore the route of doing our own formatting.
For that matter, do we have any assurance that the formatting of doubles on all C/C++ platforms is reproducible and clean?

David