<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 16, 2016 at 3:59 PM, 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 3:44 PM, Nico Weber via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> On Tue, Feb 16, 2016 at 12:22 PM, Craig, Ben <<a href="mailto:ben.craig@codeaurora.org">ben.craig@codeaurora.org</a>><br>
> wrote:<br>
>><br>
>><br>
>> On 2/16/2016 1:18 PM, Nico Weber via cfe-dev wrote:<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>
>><br>
>> Not all of them :)<br>
>><br>
>> Visual Studio groups warnings into big warning level buckets.  Level 1 has<br>
>> the most important / severe (obvious use of uninitialized value), level 4<br>
>> has fairly minor warnings (unused parameter), and /Weverything will tell you<br>
>> about really useless stuff (warning! you just used __declspec(align)! ).  I<br>
>> could imagine a world where the "Level 1", and maybe "Level 2" warnings were<br>
>> errors by default.<br>
><br>
><br>
> We have this too: on-by-default warnings, -Wall, -Wextra, -Weverything. I<br>
> don't think we should turn on-by-default warnings into errors.<br>
<br>
</span>We already do (in fact, we have over two dozen that we turn on,<br>
according to the list posted earlier in the thread).<br></blockquote><div><br></div><div>But that's for things that are supposed to be errors but can't be due to system headers, not the other way round.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> We should make it harder to compile broken code, and easier to write<br>
>> correct code.  We can't change it all at once without angering the world<br>
>> though :)<br>
><br>
><br>
> People who don't like writing broken code don't ignore warnings. People who<br>
> do like writing broken code will just pass -Wno-error. I don't think this<br>
> proposal helps either party.<br>
<br>
</span>I think there's a reasonable distinction between "this code may not do<br>
what you expect" and "this code may not do what you expect, and is<br>
likely to result in security vulnerabilities."</blockquote><div><br></div><div>"may not be what you expect" can always be a security vulnerability – think of -Wfor-loop-analysis, -Wunreachable, etc. We have warnings with much higher true positive rate than -Wformat-security.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If someone elects to<br>
turn on -Wno-error to get their insecure code to compile, there's<br>
basically no help for them. But for projects that don't compile<br>
particularly cleanly (so security-related diagnostics get lost in the<br>
noise)</blockquote><div><br></div><div>If our default warning set is too noisy, that's a bug. Every on-by-default warning should be super useful -- that's the bar for on-by-default warnings.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">, being alerted, "no, really, this is bad" will definitely help<br>
*some* programmers. I am interested in alerting people who might be<br>
willing to fix security vulnerabilities in their code. I'm unconcerned<br>
about people who will go to any lengths to get their code to compile<br>
without actually fixing their code when it comes to security concerns.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><span class="im HOEnZb"><br>
><br>
>><br>
>><br>
>><br>
>> --<br>
>> Employee of Qualcomm Innovation Center, Inc.<br>
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux<br>
>> Foundation Collaborative Project<br>
>><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> _______________________________________________<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></div>