Compiler printf format checking

[Dmitry Samersoff]

On 2013-12-17 14:07, Staffan Larsen wrote:
> 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.

Correct!

> 
> 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).
Pros: Consistent output on all supported platforms at low cost
Pros: Ability to catch more errors with asserts.
Pros: Simplify code with new format macros like %K for Klass

> 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.
Con: might have negative performance impact

-Dmitry

> 
> 
> 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.
> 


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