<div dir="ltr">Let me attempt a summary here:<div><br></div><div>* For the specific warning, it sounds like making it more useful (give it a fixit, improve error text -- see the bug that was just linked to, etc) will likely make people pay more attention to it</div><div>* It sounds like a "warning level" concept is considered useful by some since there's too much stuff on by default (?) and the jump from "default warnings" to "-Wall" is too big. From what I gathered, people want something more granular than default, -wall, -wextra, but something less granular than turning individual groups on and off.</div><div>* Some people think it might make sense to turn on warnings-as-errors for lower warning levels.</div><div>* But that's contested, and it's also not clear if -Wformat-security would be in a low warning level category.</div><div><br></div><div>So I think the consensus to the question in the original post is what Reid said ("My feeling is that we shouldn't do this in upstream clang. [...]<span style="font-size:12.8px"> think it's totally reasonable for vendors to want to make this default to an error, though</span>").</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 17, 2016 at 3:04 PM, Alexander Riccio via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#ffffff"><div><div style="font-family:Calibri,sans-serif;font-size:11pt">I think the recent bug I opened up is pertinent, as it's not clearly (for some people, like me) bad code at fault:<br><br><a href="https://llvm.org/bugs/show_bug.cgi?id=26643" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=26643</a><br><br>sent from my (stupid) windows phone</div></div><div dir="ltr"><hr><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">From: </span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">Craig, Ben via cfe-dev</a></span><br><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Sent: </span><span style="font-family:Calibri,sans-serif;font-size:11pt">2/17/2016 4:10 PM</span><br><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">To: </span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:chisophugis@gmail.com" target="_blank">Sean Silva</a>; <a href="mailto:aaron@aaronballman.com" target="_blank">Aaron Ballman</a></span><br><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Cc: </span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev</a></span><br><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Subject: </span><span style="font-family:Calibri,sans-serif;font-size:11pt">Re: [cfe-dev] RFC: default to -Werror=format-security</span><br><br></div><div><div class="h5">
On 2/17/2016 3:03 PM, Sean Silva via cfe-dev wrote:<br>
<blockquote type="cite">
<div dir="ltr">On Wed, Feb 17, 2016 at 5:27 AM, Aaron Ballman via
cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><span>On Wed, Feb 17, 2016 at 3:48 AM, David Chisnall<br>
<<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>>
wrote:<br>
> On 16 Feb 2016, at 21:56, Aaron Ballman via cfe-dev
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:<br>
>><br>
>> Sorry, but printf(fmt); is *always* a true
positive in my book. Same<br>
>> with failing to return from all code paths.
(etc)<br>
><br>
> You are wrong. The most common reason for
printf(fmt) to appear is that fmt is the result of doing
a lookup of the locale-aware version of some constant
string. In this case, the contents of fmt is entirely
under the control of whoever shipped the application,
and will have been checked for format string
vulnerabilities by the localisation tools (at least,
assuming that the original that is being translated are
free from vulnerabilities). If you are not doing any
caching in the application, then you can mark the
translation function with the attribute that indicates
that its input and output have the same format string
compatibility. If you are caching, then there is no
easy way of silencing this warning.<br>
><br>
> Making this an error will cause valid and correct
code to fail to compile and will result in people simply
disabling the warning, rather than checking it.<br>
<br>
</span>If the expected string does not have any format
specifiers, then<br>
printf("%s", fmt) is definitely the correct way to write
that because<br>
the assumption "entirely under the control of whoever
shipped the<br>
application" is a poor one. If it does have format
specifiers, I agree<br>
that we should not err, but I don't believe that was on
the table.<br>
</blockquote>
<div><br>
</div>
<div>I think David is talking about a situation where it is
e.g.</div>
<div><br>
</div>
<div>printf(translate("Please enter a number from %d-%d\n"),
lo, hi);</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Note from the original post:<br>
"This warning complains about a printf-like format string that
is not a literal string and is used without any arguments."<br>
That means that 'printf(translate("Please press OK to continue"));'
would trigger this warning (rightfully). But the example you gave
would not trigger the warning, as the invocation has extra 'lo' and
'hi' arguments.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>-- Sean Silva</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><br>
~Aaron<br>
<div>
<div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
cfe-dev mailing list
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</div></div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>