Pointer formats, again...

[Dmitry Samersoff]

David,

Other approach might be to create a simple wrapper[1] that parse
format string and fix platform-related issues.

It would cost a bit of performance but makes code much more cleaner (no
format macros), and allow us to don't spend efforts to this problem anymore.


[1] This is an example of such wrapper I wrote about 10 years ago,
to solve similar problem.

http://libdms.cvs.sourceforge.net/viewvc/libdms/libdms4/src/Util/dsform.C?revision=1.4&view=markup

-Dmitry

On 2014-05-10 22:02, David Chase wrote:
> 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
> 
> 
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.