Compiler printf format checking
mikael.vidstedt at oracle.com
Wed Dec 11 13:14:18 PST 2013
I'm not sure I immediately see how writing our own printf would help us leverage the compiler format/argument checker?
> On Dec 11, 2013, at 6:46, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
> 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
> It makes code much more readable and safe.
> e.g. (I wrote it back in 2004)
>> 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)
>>> On 2013-12-03 11:13, Staffan Larsen wrote:
>>> Looks good!
>>> (we should use "__attribute__ format" to let the compiler catch these
>>>> 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/
>>>> Tested on reported platform, which is Linux 32 bit.
> 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