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

[Nico Weber via cfe-dev]

Let me attempt a summary here:

* 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
* 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.
* Some people think it might make sense to turn on warnings-as-errors for
lower warning levels.
* But that's contested, and it's also not clear if -Wformat-security would
be in a low warning level category.

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. [...] think
it's totally reasonable for vendors to want to make this default to an
error, though").

On Wed, Feb 17, 2016 at 3:04 PM, Alexander Riccio via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I think the recent bug I opened up is pertinent, as it's not clearly (for
> some people, like me) bad code at fault:
>
> https://llvm.org/bugs/show_bug.cgi?id=26643
>
> sent from my (stupid) windows phone
> ------------------------------
> From: Craig, Ben via cfe-dev <cfe-dev at lists.llvm.org>
> Sent: ‎2/‎17/‎2016 4:10 PM
> To: Sean Silva <chisophugis at gmail.com>; Aaron Ballman
> <aaron at aaronballman.com>
> Cc: cfe-dev <cfe-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] RFC: default to -Werror=format-security
>
> On 2/17/2016 3:03 PM, Sean Silva via cfe-dev wrote:
>
> On Wed, Feb 17, 2016 at 5:27 AM, Aaron Ballman via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Wed, Feb 17, 2016 at 3:48 AM, David Chisnall
>> <David.Chisnall at cl.cam.ac.uk> wrote:
>> > On 16 Feb 2016, at 21:56, Aaron Ballman via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>> >>
>> >> Sorry, but printf(fmt); is *always* a true positive in my book. Same
>> >> with failing to return from all code paths. (etc)
>> >
>> > 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.
>> >
>> > 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.
>>
>> If the expected string does not have any format specifiers, then
>> printf("%s", fmt) is definitely the correct way to write that because
>> the assumption "entirely under the control of whoever shipped the
>> application" is a poor one. If it does have format specifiers, I agree
>> that we should not err, but I don't believe that was on the table.
>>
>
> I think David is talking about a situation where it is e.g.
>
> printf(translate("Please enter a number from %d-%d\n"), lo, hi);
>
>
> Note from the original post:
>     "This warning complains about a printf-like format string that is not
> a literal string and is used without any arguments."
> 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.
>
> -- Sean Silva
>
>
>>
>> ~Aaron
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
>
> _______________________________________________
> cfe-dev mailing listcfe-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> --
> 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/20160217/93f2f2ec/attachment.html>