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