[9] RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang

[David Chase]

On 2014-05-08, at 7:06 AM, David Chase <david.r.chase at oracle.com> wrote:
> On 2014-05-08, at 3:37 AM, David Holmes <david.holmes at oracle.com> wrote:
>> On 8/05/2014 11:13 AM, David Chase wrote:
>>> 
>>> On 2014-05-07, at 7:59 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>> So this has been a lot of work and a lot of information over email. I had one question - why isn't there a FORMAT type that can be used for void* ?  Using these p2i functions is going to get really annoying.
>>> 
>>> What I understand, from reading stackoverflow and poking around, is that %p does not have a uniform behavior across platforms; some of them prefix a 0x, others do not.  I think there is variance in how the width can be specified, not sure.
>>> 
>>> If we can sort out the %p variation, perhaps by defining PTR_FORMAT to be either 0x%p or %p depending on the platform, and if we can sort out width issues also, then we could get rid of INTPTR_FORMAT (convert to PTR_FORMAT) and remove the p2i casts.
>> 
>> I hate to say this, but figuring out the compiler-specific behaviour for %p would seem to involve far less effort and change, than converting all pointers using p2i and changing from PTR_FORMAT to INTPTR_FORMAT. It may even be something that configure can work out for us at configure time ??
> 
> I have this nagging suspicion that you are right.  I should at least make the effort to see what happens if I use a %08p format on all platforms of alleged interest.

Here's my test program:

#include <stdio.h>
int main(int argc, char ** argv) {
   printf("Hello world, %4p\n", argv);
   printf("Hello world, %16p\n", argv);
   printf("Hello world, %016p\n", argv);
   return 1;
}

On gcc-ish systems, this prints things like

Hello world, 0x7fff573d9ca0
Hello world,   0x7fff573d9ca0
Hello world, 0x007fff5379e9e0

HOWEVER, I get inconsistent compilation warnings for %016p
gcc-4.5 and gcc-4.8 (no warnings)
XCode 5 (clang):  hellop.c:5:26: warning: flag '0' results in undefined behavior with 'p' conversion specifier [-Wformat]
clang-3.1: hellop.c:5:26: warning: flag '0' results in undefined behavior with 'p' conversion specifier [-Wformat]
XCode 4.6 (gcc):  hellop.c:5: warning: '0' flag used with ‘%p’ printf format (printed twice for a single line)

Solaris studio (12.3, on Solaris 11 x86) prints

Hello world, feffeac0
Hello world,         feffeac0
Hello world, 00000000feffeac0

Visual Studio 2010

Hello world, 00E330D0
Hello world,         00E330D0
Hello world,         00E330D0

Note that Windows yells at you for pointers, but not for hex formatting.

We could handle this mix of behaviors with a conditional definition (leading 0x or not) as long as
we did not care too much about the width of the format.

I.e., 

#if defined __GNUC__
#define PTR_FORMAT %p
#else
#define PTR_FORMAT 0x%p
#endif

What do we think of this?
Can we get an adequate value of "we" before we inflict this on everyone else?

David