[cfe-commits] r140777 - in /cfe/trunk: lib/Sema/SemaChecking.cpp test/Sema/format-strings.c

[Ted Kremenek]

The 'format' attribute already states whether or not it takes 'printf' or 'scanf' format strings.  That's not really the issue here.  The issue is whether or not the function is a no-op given an empty format string.  For a 'scanf' format string, it's clearly a no-op given no format string.  For a 'printf' format string, that's not necessarily the case.

On Sep 30, 2011, at 11:07 AM, Ahmed Charles wrote:

> Without knowing the context perfectly, is it possible to annotate the function in a way that expresses which set of format strings it accepts? Of there are two sets of behaviors from format strings, then having a way to identify each makes sense.
> From: Ted Kremenek
> Sent: 9/30/2011 12:45 AM
> To: Joerg Sonnenberger
> Cc: llvm cfe
> Subject: Re: [cfe-commits] r140777 - in /cfe/trunk: lib/Sema/SemaChecking.cpp test/Sema/format-strings.c
> 
> On Sep 30, 2011, at 12:38 AM, Ted Kremenek wrote:
> 
>> On Sep 29, 2011, at 11:51 PM, Joerg Sonnenberger wrote:
>> 
>>> On Thu, Sep 29, 2011 at 04:01:39PM -0700, Ted Kremenek wrote:
>>>> This isn't just about printf and scanf, but any function with the format attribute.  There are functions with that attribute where this isn't a no-op even when the format string is empty.  I saw such a case, which was the motivation for this change.
>>>> 
>>>> That said, the warning definitely is useful for printf and friends when there are no data arguments.  I'd like the warning to be the strictest when it can be.
>>> 
>>> Why not support -W(no-)format-zero-length like GCC then?
>> 
>> Clang does support that, and I don't think it is so simple.
>> 
>> Passing -Wno-format-zero-length means the warning never fires at all, even in legit cases (like the ones you pointed out).
>> 
>> Using pragmas to silence the warning within smaller blocks of code is also not user friendly, as it requires using it on every callsite that the warning triggers.
> 
> Along the pragmas line, the only solution that I know of that would work without silencing the warning outright would be to wrap the original function in a macro that surrounded the function call with _Pragmas that silenced the warning.  That's obviously not a great experience.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110930/48ddfd5c/attachment.html>