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

[David Holmes]

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?

> src/hotspot/share/utilities/globalDefinitions.hpp line 163:
> 
>> 161: // Format pointers which change size between 32- and 64-bit.
>> 162: #ifdef  _LP64
>> 163: #define INTPTR_FORMAT            "0x%016"     PRIxPTR
> 
> pre-existing: The naming of INTPTR_FORMAT is inconsistent with the other integer formatters because the "X_0" suffix is missing and padded hex printing is implicit. It's a (slightly shorter) syntactic synonym for the (not currently defined) INTX_FORMAT_X_0. While reviewing this change I noticed several uses of INTPTR_FORMAT that seemed like they should be PTR_FORMAT. I'm not entirely sure what the intended usage for INTPTR_FORMAT might be.  I wonder what would be left after making a pass looking carefully at uses of INTPTR_FORMAT.

See my related comment above. I think because of lack of %p, and possibly some typing issues we have general confusion about whether we can print pointers directly or whether we have to convert them to an integral type, ie intptr_t, first using p2i.

-------------

PR: https://git.openjdk.org/jdk/pull/10042