Compiler printf format checking

[Dmitry Samersoff]

Mikael,

On 2013-12-12 01:14, Mikael Vidstedt wrote:
> I'm not sure I immediately see how writing our own printf would help us leverage the compiler format/argument checker?

Compiler recognize printf() and didn't care about implementation it
really uses. So if we can just use %p on all platforms - compiler will
check the arguments.

Also with our own implementation we can add as many asserts as we want
and have nightly-time failure instead of hidden bug.

-Dmitry


> 
> Cheers,
> Mikael
> 
>> On Dec 11, 2013, at 6:46, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
>>
>> 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.


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