Compiler printf format checking

Zhengyu Gu at
Wed Dec 4 06:06:28 PST 2013

Yes. That is exactly what I saw. We have to cast all pointers for using 
PRT_FORMAT, etc. or we get compile errors, something like:

error: format '%08x' expects type 'unsigned int', but argument 3 has 
type 'Thread*'



On 12/3/2013 6:50 PM, Mikael Vidstedt wrote:
> FWIW - I played around with doing exactly that a year ago or so. The 
> biggest (and only) problem I found is that we have a large number of 
> places where we want to print pointers using various formats 
> (sometimes with "0x" prefix, sometimes using zero padding, etc.). The 
> only valid printf format specifier for pointers is '%p', and the exact 
> output of '%p' is not specified, much less as flexible as we need it 
> to be.
> What that that effectively means is that we'd have to cast any and all 
> pointer arguments to printf-style functions, something like:
> tty->print("The pointer: " PTR_FORMAT, ptr);
> would have to become:
> tty->print("The pointer: " PTR_FORMAT, (uintptr_t)ptr);
> This will obviously pollute the code, but would enable using 
> __attribute__((format...)) & friends. If I remember correctly there 
> are ~1000 or so places where a cast would have to be added. It was 
> unclear to me at the time if that was something we were willing to do.
> (I also investigated if there are ways to (mis-)use templates to work 
> around the cast issue, but as far as I can tell that is not possible)
> Cheers,
> Mikael
> On 2013-12-03 11:13, Staffan Larsen wrote:
>> Looks good!
>> (we should use "__attribute__ format" to let the compiler catch these 
>> problems)
>> Thanks,
>> /Staffan
>> On 3 dec 2013, at 19:31, Zhengyu Gu < at> wrote:
>>> This is a simple fix in context of nightly failures cleaning up. The 
>>> fix will go into JDK 9 once the repository is open.
>>> Bug:
>>> Webrev:
>>> Test:
>>>   Tested on reported platform, which is Linux 32 bit.
>>> Thanks,
>>> -Zhengyu

More information about the hotspot-runtime-dev mailing list