Re: format string is not a string literal

On Wed, Feb 25, 2015 at 6:35 PM, Andrew Pinski <[email protected]> wrote:
> On Wed, Feb 25, 2015 at 6:30 PM, Simon Marchi <[email protected]> wrote:
>>>> On Feb 25, 2015, at 4:41 PM, Jack Howarth <[email protected]> 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.

Thanks,
Andrew



> Thanks,
> Andrew
>
>>
>> Simon