RFR: 8292981: Unify and restructure integer printing format specifiers [v3]

[David Holmes]

I think this was an email-only comment ...

On 30/08/2022 2:11 pm, Kim Barrett wrote:
>> On Aug 29, 2022, at 8:55 PM, David Holmes <dholmes at openjdk.org> wrote:
>>
>> On Mon, 29 Aug 2022 22:46:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>>
>>>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>>>>
>>>>   Use PTR_FORMAT in AIX code
>>>
>>> src/hotspot/share/runtime/deoptimization.cpp line 1904:
>>>
>>>> 1902:
>>>> 1903:   // Log a message
>>>> 1904:   Events::log_deopt_message(current, "Uncommon trap: trap_request=" INT32_FORMAT_X_0 " fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT,
>>>
>>> pre-existing: (first only) s/INTPTR_FORMAT/PTR_FORMAT/.
>>
>> I'm confused now about whether we use `p2i(x)` with `PTR_FORMAT` or `INTPTR_FORMAT`? `p2i` converts a pointer to an int so the resulting type should be `intptr_t` and so the format should be `INTPTR_FORMAT` - is that not so?
> 
> I think PTR_FORMAT should always be used with the result of p2i — we’re printing a pointer.

So the p2i is just a hack to get around the fact gcc won't let us print 
a pointer directly using integer format specifiers?

> I think using INTPTR_FORMAT with the result of p2i is a bug (though one that only affects code understanding, not execution).

I think this is something we actively did a few years back when 
addressing missing p2i usage. But I was probably ther advocate of doing 
it this way.

Cheers,
David
-----

> I think if we went through and fixed all of those misuses of INTPTR_FORMAT, some of the remaining
> uses of it might be more appropriately using something else, like one of the INTX_FORMAT variants.



> And I wonder what the residue from dealing with those might be - perhaps empty?
>