[cfe-dev] RFC: default to -Werror=format-security

[Nico Weber via cfe-dev]

On Tue, Feb 16, 2016 at 3:59 PM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Tue, Feb 16, 2016 at 3:44 PM, Nico Weber via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > On Tue, Feb 16, 2016 at 12:22 PM, Craig, Ben <ben.craig at codeaurora.org>
> > wrote:
> >>
> >>
> >> On 2/16/2016 1:18 PM, Nico Weber via cfe-dev wrote:
> >>>
> >>>
> >>> Won't this line of reasoning lead to all useful warnings being in
> -Werror
> >>> eventually? Say, forgetting a return statement in a function is also
> "just"
> >>> a warning...
> >>
> >>
> >> Not all of them :)
> >>
> >> Visual Studio groups warnings into big warning level buckets.  Level 1
> has
> >> the most important / severe (obvious use of uninitialized value), level
> 4
> >> has fairly minor warnings (unused parameter), and /Weverything will
> tell you
> >> about really useless stuff (warning! you just used __declspec(align)!
> ).  I
> >> could imagine a world where the "Level 1", and maybe "Level 2" warnings
> were
> >> errors by default.
> >
> >
> > We have this too: on-by-default warnings, -Wall, -Wextra, -Weverything. I
> > don't think we should turn on-by-default warnings into errors.
>
> We already do (in fact, we have over two dozen that we turn on,
> according to the list posted earlier in the thread).
>

But that's for things that are supposed to be errors but can't be due to
system headers, not the other way round.


> >> We should make it harder to compile broken code, and easier to write
> >> correct code.  We can't change it all at once without angering the world
> >> though :)
> >
> >
> > People who don't like writing broken code don't ignore warnings. People
> who
> > do like writing broken code will just pass -Wno-error. I don't think this
> > proposal helps either party.
>
> I think there's a reasonable distinction between "this code may not do
> what you expect" and "this code may not do what you expect, and is
> likely to result in security vulnerabilities."


"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.


> If someone elects to
> turn on -Wno-error to get their insecure code to compile, there's
> basically no help for them. But for projects that don't compile
> particularly cleanly (so security-related diagnostics get lost in the
> noise)


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.


> , being alerted, "no, really, this is bad" will definitely help
> *some* programmers. I am interested in alerting people who might be
> willing to fix security vulnerabilities in their code. I'm unconcerned
> about people who will go to any lengths to get their code to compile
> without actually fixing their code when it comes to security concerns.
>
> ~Aaron
>
> >
> >>
> >>
> >>
> >> --
> >> Employee of Qualcomm Innovation Center, Inc.
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux
> >> Foundation Collaborative Project
> >>
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160216/704297e4/attachment.html>