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

Ahmed Charles ahmedcharles at gmail.com
Fri Sep 30 11:07:33 PDT 2011


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/4247070f/attachment.html>


More information about the cfe-commits mailing list