Compiler printf format checking

Dmitry Samersoff dmitry.samersoff at oracle.com
Wed Dec 11 06:46:28 PST 2013


Mikael,

Other option is to create our own, platform independent implementation
of printf (not necessary complete, just what we need from
it) either from scratch or on top of iostream and get rid of all format
macros.

It makes code much more readable and safe.

e.g. (I wrote it back in 2004)

http://libdms.cvs.sourceforge.net/viewvc/libdms/libdms5/parts/Crux/src/dsForm.cxx?revision=1.1&view=markup

-Dmitry

On 2013-12-04 03:50, 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 <zhengyu.gu at oracle.com> 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: https://bugs.openjdk.java.net/browse/JDK-8026300
>>> Webrev:  http://cr.openjdk.java.net/~zgu/8026300/webrev.00/
>>>
>>> Test:
>>>   Tested on reported platform, which is Linux 32 bit.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


More information about the hotspot-runtime-dev mailing list