Pointer formats, again...

[Staffan Larsen]

On 12 maj 2014, at 09:35, David Holmes <david.holmes at oracle.com> wrote:

> Hi Staffan,
> 
> On 12/05/2014 5:26 PM, Staffan Larsen wrote:
>> Just wondering if it is worth the time and energy to get the exact same formatting of pointers across all platforms. After all, they are details of the underlaying implementation and you wouldn’t normally compare output across platforms. Yes, I agree that “0xnull” isn’t a pretty output, but we all understand what it means. To me at least, it is more important that the code looks good and is easy to read and write.
> 
> I think the issue is with the use of printed pointer values in regular logging output. If that format changed in unexpected ways due to the use of %p then it could break a lot of external log parsers.

I guess I don’t agree that this is a priority, I may be wrong. It’s just an inordinate amount of time spent.

My $0.02,
/Staffan

> 
> The vicious circle here is that to get standardized output we can't use %p, but then we get the type mismatches that gcc warns about, which then requires the use of p2i and INTPTR_FORMAT which then raises the "why can't we just use %p?" question which ... :)
> 
> The gcc warnings have forced action here (annoyingly so if you ask me) but we've known for years that this is a mess with no simple means of cleaning it up.
> 
> David H.
> 
>> /Staffan
>> 
>> On 10 maj 2014, at 20:02, David Chase <david.r.chase at oracle.com> 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
>>> 
>>> 
>>> 
>>