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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
