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

[David Chase]

On 2014-04-28, at 6:12 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> The same as John said:
> 
> Use print_raw(msg) for now and file RFE to rename (I prefer puts()).
> Use cr() for empty strings.

Done, except for the pending RFE.

> os_linux.cpp: you can include space into format now after you added "%s"
> 
> -  st->print("%s", os::Linux::glibc_version()); st->print(" ");
> ---
> +  st->print("%s ", os::Linux::glibc_version());
> 
> Do the same in your changes in os_posix.cpp instead of using print_raw().

Done.

> I don't like "0x%" PRIxPTR combination. Can you use PTR_FORMAT instead of "0x%" PRIxPTR ?:
> 
> +    case T_OBJECT: out->print("obj:0x%" PRIxPTR, p2i(as_jobject()));      break;
> +    case T_METADATA: out->print("metadata:0x%" PRIxPTR, p2i(as_metadata()));break;

Done.  Note that this will change the output -- PTR_FORMAT is 8 or 16 hex digits, always.

> and INTPRT_FORMAT for:
> 
> out->print("%3d:0x" UINT64_FORMAT_X, type(), (uint64_t)as_jlong());

This gets messy, because the only reliable name I have for a 64-bit type and format is [u]int64.
Pointers can be 32-bits wide on some platforms.  (So no, I actually can't make this work.)

> The places with absent '0x' should be fixed IMHO. For example in c1_Runtime1.cpp: 'at pc %" PRIxPTR,'

Done. Replaced with PTR_FORMAT, which includes the 0x (and 8 or 16 hex digits always).

> Can you fix vm_version_<arc>.cpp by casting flags values to (int)?

I would prefer not to -- this could have wider effects than the format fixes I have made, and that would require a lot of testing with a lot of different flag values to be sure I didn't screw something else up unintentionally.

> arguments.cpp: Can you use (uint) instead of (unsigned int)?

Done

All instances of "Done" passed preliminary testing, and I'll redo all the other testing tomorrow.

David