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

[John Rose]

On May 9, 2014, at 1:03 AM, Mike Duigou <mike.duigou at oracle.com> wrote:

> 
> On May 8 2014, at 22:52 , John Rose <john.r.rose at oracle.com> wrote:
> 
>> On May 8, 2014, at 8:04 PM, David Holmes <david.holmes at oracle.com> wrote:
>> 
>>> But surely the p2i + INTPTR_FORMAT change is an even bigger revert! Unless you propose to keep using PTR_FORMAT even with p2i ? (In case it is half as big a revert but still big).
>>> 
>>> Put another way, once you've done the p2i+INTPTR_FORMAT change, what incentive is there to fix the %p issue and revert everything you just changed? This seems like a now-or-never fix to me.
>> 
>> It would be.  And I advise "never".  I don't think we should chase "%p".  (Or continue chasing Chase.)
> 
> Why not?

I guess it's a fair question, though in part it is also a FAQ:  http://stackoverflow.com/questions/2369541/where-is-p-useful-with-printf

> using %X for a non integer format has always seemed lame. For a few environments I've even had nice features such as %p of a function pointer printing out the name of the function. Why is %p not worth the effort? (Or why is %X better?)

Our platform needs to behave with Java-level portability, which is more stringent than C-level portability.

Output from the JVM should not use %p, if we intend users to see it, because %p has platform-dependent meaning.  In practical terms, this means we should not be using %p anywhere, because it is sometimes hard to predict when something printed by the JVM graduates from an internal debugging aid to something users like to look at.  (BTW, I don't want to make a firm process for distinguishing the two things; we have better things to do.)

The variations are sometimes by design: Sometimes %p has "nice" features like printing the name of the pointer instead of the value (most often the name "null").  More often it is because %p has not-nice mis-features due to its shady specification, like sometimes ignoring the '0' in '%0p' or shouting in upper case hex, or unpredictably prepending '0x'.

This is not one of this cases where some well-meaning cleanup programmer is throwing away something useful.  The misbehavior of %p is one of the central reasons our formatting code is painful.  (The lack of portable size-specific format modifiers is the other.)

For integer or address output that is going to represent the JVM's activities to customers, we need to be satisfied with signed decimal, unsigned decimal, and hexadecimal, in 32 and 64 bit formats.  Those are that formats that we can reliably squeeze out of printf and friends (with considerable effort).  Or else we need to roll our own pointer presentations (see the disassembler).  But, as I said, we should stop chasing %p.  It is a will-o-the-wisp that has (once again) led us into a swamp.

— John