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

[David Holmes]

On 30/04/2014 9:59 PM, David Chase wrote:
>
> On 2014-04-30, at 5:09 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> How do you like it otherwise?  I'm itching to get reviews and get this thing out of my hair.
>>
>> I appreciate what you are doing but I dislike the details - in particular print_raw and, even worse, cr().
>>
>> One thing we do need from this is some clear documentation somewhere on what format specific macros to use for which types.
>
> You do understand that those are both existing public methods, and I did not add or innovate, right?

I didn't blame you for their existence, I just dislike the proliferation 
of their use. I was not aware of either of them before this thread, and 
have no recollection of encountering them.

> It's also completely nonintuitive to me that you would dislike cr more than print_raw.

s->print_raw(...) at least is obviously printing

s->cr() is what? print_cr at least puts the cr in the context of printing.

> Rather than document, we could make them not be public, if we really meant for them not to be called.
> I prefer Vladimir's proposal to rename print_raw into puts.

I would not be averse to that. :)

> One thing that is a little puzzling to me is why we have both INTX and INT64.
> I see no purpose whatsoever for INTX; it appears to be a 64-bit integer type,
> but we have a well-defined 64-bit integer type (INT64) and a not-well-defined
> 64-bit integer type (JLONG) that we own because it is Ours.  We also have a
> pointer-sized integer type (INTPTR) and if this is actually a distinction,
> an "I intend to print this integer as a pointer type" (PTR).

As Vladimir points out intx is not a 64-bit integer type, but an 
intptr_t that varies in size. Why we needed that instead of just using 
intptr_t I have no idea.

David H.

> David
>