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

[Stefan Karlsson]

On Thu, 1 Sep 2022 13:37:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. 
>> 
>> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR<size>_FORMAT to print integers with the format 0x000<value>. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that.
>> 
>> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x.
>> 
>> I'd like to suggest that we use a convention to specify what we want. This is the current proposal:
>> 
>> // Guide to the suffixes used in the format specifiers for integers:
>> //        - print the decimal value:                   745565
>> //  _X    - print as hexadecimal, without leading 0s: 0x12345
>> //  _X_0  - print as hexadecimal, with leading 0s: 0x00012345
>> //  _H    - print as hexadecimal, without 0x prefix
>> //  _W(w) - prints w sized string with the given value right
>> //          adjusted. Use -w to print left adjusted.
>> //
>> // Note that the PTR format specifiers print using 0x with leading zeros,
>> // just like the _X_0 version for integers.
>> 
>> 
>> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers.
>
> Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Add gtest
>  - Fix INTX_FORMAT_X and UINTX_FORMAT_X
>  - Remove unintuitive _X_W versions

Thanks all for the discussion.

Now that we have sort-of agreed on a first version of the naming convention for these macros, I ran this through testing and created a gtest.

* I found that it was very easy to abuse the _X_W versions, because:
1) The padding didn't count the 0x characters
2) Right justified specifiers caused strings like this: 0x   123

so I inlined the usage of it.

* Also found that INTX_FORMAT_X/UINTX_FORMAT_X didn't convert to hex

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

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