Compiler printf format checking

Staffan Larsen staffan.larsen at oracle.com
Tue Dec 17 02:07:39 PST 2013


So to sum this up we have for __attribute__(format):

Pro: 	Catches errors in format strings early
Con: Need lots of additional casts for pointer arguments.

We have an alternative which is to implement our own format string handling:

Pros: Better control over how, eg %p, is rendered. No need for casting or format specifier macros (PTR_FORMAT and friends).
Con: More complicated code to maintain. Can’t use __attribute__(format) so we can’t get the compiler to verify the format strings for us.


Correct?

/Staffan



On 13 dec 2013, at 20:49, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:

> Mikael,
> 
> With our own implementation of printf we can do whatever we whant - i.e.
> add zero by default to all %p output.
> 
> With stock implementation (gnu_printf) - yes, we have to cast.
> 
> Personally, I have a long standing dream to get rid of all formatting
> macros we have today - it makes code less readable.
> 
> -Dmitry
> 
> 
> 
> On 2013-12-13 23:05, Mikael Vidstedt wrote:
>> 
>> Dmitry,
>> 
>> Right, so unless I'm missing something that means we're back to adding
>> casts in all the places we want zero padded pointer values (which today
>> is the default when using PTR_FORMAT & friends)?
>> 
>> Cheers,
>> Mikael
>> 
>> On 2013-12-13 01:14, Dmitry Samersoff wrote:
>>> Mikael,
>>> 
>>> Leading zero is not a part of C99 specification, so gcc warn about it.
>>> 
>>> You can omit zero and in this case no extra warning happens.
>>> 
>>> 
>>> Correct C99 way to print pointer with leading zeroes is
>>> 
>>> printf("%08" PRIxPTR "\n", (uintptr_t)my_ptr);
>>> 
>>> but we are loosing compiler warning.
>>> 
>>> 
>>> -Dmitry
>>> 
>>> On 2013-12-13 07:12, Mikael Vidstedt wrote:
>>>> I get this on Linux:
>>>> 
>>>> int
>>>> main(void)
>>>> {
>>>>   printf("%08p", NULL);
>>>>   return 0;
>>>> }
>>>> 
>>>> $ gcc -Wall -o tst tst.c
>>>> tst.c: In function âmainâ:
>>>> tst.c:6:3: warning: '0' flag used with â%pâ gnu_printf format [-Wformat]
>>>> 
>>>> /Mikael
>>>> 
>>>> On 2013-12-12 13:52, Dmitry Samersoff wrote:
>>>>> On 2013-12-12 05:14, Mikael Vidstedt wrote:
>>>>>> Are we saying the gcc format checking ignores any qualifiers on %p,
>>>>>> yet
>>>>>> correctly treats it as a pointer format? That is, if we use something
>>>>>> like "%08p", will gcc still recognize that as a pointer format and
>>>>>> look
>>>>>> for a pointer argument (without complaining)?
>>>>> Int arg:
>>>>> 
>>>>> dooku:dms#cc test.c
>>>>> test.c: In function ‘main’:
>>>>> test.c:8:2: warning: format ‘%8p’ expects type ‘void *’, but argument 2
>>>>> has type ‘int’
>>>>> 
>>>>> Pointer arg compiles silently.
>>>>> 
>>>>> -Dmitry
>>>>> 
>>>>>> Cheers,
>>>>>> Mikael
>>>>>> 
>>>>>> On Dec 11, 2013, at 3:06 PM, John Rose <john.r.rose at oracle.com
>>>>>> <mailto:john.r.rose at oracle.com>> wrote:
>>>>>> 
>>>>>>> On Dec 11, 2013, at 2:41 PM, Dmitry Samersoff
>>>>>>> <dmitry.samersoff at oracle.com <mailto:dmitry.samersoff at oracle.com>>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> we can just use %p on all platforms
>>>>>>> That's clever.
>>>>>>> 
>>>>>>> I do think we need to use an off-the-shelf static analyzer for the
>>>>>>> format strings.  There is only a tiny amount of room to maneuver
>>>>>>> within the confines of the language of printf format strings.
>>>>>>> 
>>>>>>> There are probably several other fiddly details like this, such as
>>>>>>> "how do I format intptr_t" and "how do I format jlong" and maybe "how
>>>>>>> do I format an oop".  It may be possible to do some dodges like %p to
>>>>>>> get around those also.  (The [-+#] modifiers look tantalizing to
>>>>>>> me in
>>>>>>> this regard.)
>>>>>>> 
>>>>>>> — John
>>> 
>> 
> 
> 
> -- 
> 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