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

[David Chase]

On 2014-05-08, at 5:47 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> On May 8 2014, at 14:08 , David Chase <david.r.chase at oracle.com> wrote:
>> 
>> 1) investigate definition of PTR_FORMAT as some form of %p, together with a clean separation
>> of PTR_FORMAT and INTPTR_FORMAT in formatting (we should be nearly there already).
>> Do NOT do a wholesale replace of INTPTR_FORMAT.
> 
> This is something we should definitely move towards. Output form of pointers issue in the jdk repo as well. (Still many %x for pointers). Code or tests which depend upon something other than %p format should be changed/fixed.

I think we are free to move quickly for those cases where end-users have not written tools depending tightly on how we happen to already format pointers.  It's not just our code and our tests, I think that is the problem.  The two main differences I expect that will occur are changes in length, and on windows the hex output for pointers uses ABCDEF instead of abcdef.

>> 4) incremental removal of PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC
>> (This should follow resolution of follow-on bug (1), so that the PTR_FORMAT option is available).
> 
> The PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC usage seemed like a big hammer on first reading but it is much better than -Wno-error=format-literal and I am glad to see that you have a plan for being able to reduce it's use. Is there any way we can ensure that it happens and doesn't end up as maintenance rot?

mute-warnings-for-gcc had several purposes.  The main one was actually to allow me to defer decisions where I did not think I knew what was intended.  Anyplace someone was printing a pointer, that was easy, just wrap the value with p2i(), but in other cases there was (e.g.) %d used to print a size_t, and it was not clear whether the right choice was to replace the format or cast the value, and for me to make the change would make it look more intentional than it deserved (unless some future code-editor was cross-referencing portions of code to Hg histories, which seems tedious for them).  So to make these go away, I think we have to lean on each team; just comment the line, see what goes blooie, fix it, repeat.

I realized this part way through the GC code, so there are some touches there where I may have exceeded my authority, but we're talking about not more than half-a-dozen, then I got queasy and started looking for a way out.  In other parts of the code (i.e., the compiler) I was l willing to change code a little more aggressively because I had a better feel for the territory.

David