Re: format string is not a string literal

[Andrew Pinski <pinskia at gmail dot com>]

On Thu, Feb 26, 2015 at 12:39 AM, Jack Howarth
<howarth.mailing.lists@gmail.com> wrote:
> On Wed, Feb 25, 2015 at 9:38 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>> On Wed, Feb 25, 2015 at 6:35 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>>> On Wed, Feb 25, 2015 at 6:30 PM, Simon Marchi <simon.marchi@polymtl.ca> wrote:
>>>>>> On Feb 25, 2015, at 4:41 PM, Jack Howarth <howarth.mailing.lists@gmail.com> wrote:
>>>>>>
>>>>>> Andrew,
>>>>>>     See the additional comments from the llvm.org clang developers at...
>>>>>>
>>>>>> http://llvm.org/bugs/show_bug.cgi?id=22701#c5
>>>>>
>>>>> Then put this warning under a different flag. Anyways clang is broken and gdb should not change due to a broken compiler.
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>
>>>> I would not say that clang is broken or that the warning is unclear.
>>>> The flag is -Wformat-nonliteral and the warning message is "format
>>>> string is not a string  literal". I don't know how you can be more
>>>> clear and direct about the fact that the format string is not a string
>>>> literal. Looking at the code, we observe that clang is right (the
>>>> format string is indeed not a string literal). With the proper
>>>> function attributes, the compiler could do better checks and prevent
>>>> programming mistakes. Since clang pointed out this low-hanging fruit
>>>> improvement to gdb's code, why shouldn't we take advantage of it?
>>>>
>>>> Anyway, Jack, you are welcome to submit a patch for this if you feel
>>>> like it and/or file a bug if it is not already done.
>>>
>>>
>>> Except GCC documents this options differently than clang implements:
>>> -Wformat-nonliteralIf -Wformat is specified, also warn if the format
>>> string is not a string literal and so cannot be checked, unless the
>>> format function takes its format arguments as a va_list.
>>>
>>>
>>> Notice the last part of the documentation.
>>>
>>> So this again is clang implements a GCC option but does not follow the
>>> documentation of GCC.
>>> How does clang document this option?
>>>
>>
>> GCC has always documented this option this way since at least 3.1.1:
>> https://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Warning-Options.html#Warning%20Options
>>
>> And there is no user documentation for clang for this option so clang is broken.
>
> http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format

Who would have thought to look into the documentation part of the
attribute for option documentation :).
Anyways this is an documented incompatibility which means gdb should
just test if it is being compiled with clang, not add the option.
Or better yet people should push back to clang that they need to
separate out the option or have an option to be GCC compatible.

Thanks,
Andrew

>
>>
>> Thanks,
>> Andrew
>>
>>
>>
>>> Thanks,
>>> Andrew
>>>
>>>>
>>>> Simon