<div dir="ltr">I'm with Reid on this. Useful warnings should be on by default, less useful warnings shouldn't be, and if our warnings are high-signal enough then most people will look at them.<div><br>I think one problem we have for some warnings (probably including -Wformat-security) is that it's not clear from the warning text what the problem is. It'd be useful to have some document that for each warning lists the warning's motivation and common fixes and workarounds. If people don't understand a warning and just try to shut up the compiler, things usually don't end well.</div><div><br></div><div>For this warning, it'd probably help a lot to add a fixit like Ben suggested.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 11:34 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Feb 16, 2016 at 2:18 PM, Nico Weber via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> On Mon, Feb 15, 2016 at 6:04 PM, Bob Wilson via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> We’ve had a number of requests to make the format-security warning default<br>
>> to an error. This warning complains about a printf-like format string that<br>
>> is not a literal string and is used without any arguments. E.G.:<br>
>><br>
>> format-security.c:4:10: warning: format string is not a string literal<br>
>> (potentially insecure) [-Wformat-security]<br>
>>   printf(fmt);<br>
>>          ^~~<br>
>> 1 warning generated.<br>
>><br>
>> For background, if the format string can be controlled by external input,<br>
>> the security risk is that it could contain “%” characters and be used to<br>
>> clobber memory. The alternative is to use a fixed “%s” format, e.g.,<br>
>> printf(“%s”, fmt).<br>
>><br>
>> This catches real-world security holes, but sometimes people don’t pay<br>
>> attention to warnings<br>
><br>
><br>
> Won't this line of reasoning lead to all useful warnings being in -Werror<br>
> eventually? Say, forgetting a return statement in a function is also "just"<br>
> a warning...<br>
<br>
</span>I would not be opposed to that either. If it leads to an exploitable<br>
security vulnerability (such as format specifiers, failing to return<br>
on all control paths, obvious buffer under/overruns, etc), I think we<br>
should at least consider making it an error. Perhaps it can be<br>
controlled with a flag (treat-security-diagnostics-as-an-error) that<br>
is on by default.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>> . Promoting this warning to an error by default would get people’s<br>
>> attention and help motivate them to fix their code. But, the obvious<br>
>> downside is that it could be disruptive. Existing code might fail to build<br>
>> and would either require source code fixes or build changes to specify<br>
>> -Wno-error=format-security.<br>
>><br>
>> Opinions?<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>
><br>
><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>
</div></div></blockquote></div><br></div>