From: Andrew Pinski <pinskia@gmail.com>
To: Jack Howarth <howarth.mailing.lists@gmail.com>
Cc: Simon Marchi <simon.marchi@polymtl.ca>,
"Paul_Koning@dell.com" <Paul_Koning@dell.com>,
"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: format string is not a string literal
Date: Thu, 26 Feb 2015 10:18:00 -0000 [thread overview]
Message-ID: <CA+=Sn1=rFGB_Bed-EDOmA1NJaBQOEcJEKkKFBm0F6rc+WZXRDA@mail.gmail.com> (raw)
In-Reply-To: <CADtEn-0Z8crk6KQt4cN8scGOOonCfYwKHxq0ga2FKy0Dew4qaQ@mail.gmail.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
next prev parent reply other threads:[~2015-02-26 8:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 17:16 Jack Howarth
2015-02-24 18:18 ` Andrew Pinski
2015-02-24 18:04 ` Andrew Pinski
2015-02-25 7:58 ` Paul_Koning
2015-02-26 0:06 ` Jack Howarth
2015-02-26 0:12 ` Paul_Koning
[not found] ` <CAFXXi0=56gNf2GoSKkrx=bRArhjk+AhSbiu0crpdR3=df7B2BQ@mail.gmail.com>
2015-02-26 0:46 ` pinskia
2015-02-26 2:31 ` Jack Howarth
2015-02-26 2:35 ` pinskia
2015-02-26 2:38 ` Simon Marchi
2015-02-26 8:39 ` Andrew Pinski
2015-02-26 8:46 ` Andrew Pinski
2015-02-26 9:52 ` Jack Howarth
2015-02-26 10:18 ` Andrew Pinski [this message]
2015-02-26 16:26 ` Pedro Alves
2015-02-26 17:44 ` Jack Howarth
2015-02-26 19:55 ` Pedro Alves
2015-02-26 18:34 ` Paul Smith
2015-02-26 19:41 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+=Sn1=rFGB_Bed-EDOmA1NJaBQOEcJEKkKFBm0F6rc+WZXRDA@mail.gmail.com' \
--to=pinskia@gmail.com \
--cc=Paul_Koning@dell.com \
--cc=gdb@sourceware.org \
--cc=howarth.mailing.lists@gmail.com \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox