[cfe-commits] [Patch] Warn about non-standard format strings (PR12017)

Ted Kremenek kremenek at apple.com
Mon Feb 20 13:14:41 PST 2012


On Feb 20, 2012, at 12:13 PM, Nico Weber <thakis at chromium.org> wrote:

>> I still think that (presently) having no good solution to handling
>> non-portable format string specifiers doesn't mean we should just
>> unconditionally warn about them.  Consider '%S' and and '%C'.  For OS X
>> developers, it may be perfectly reasonable to use those, especially if they
>> aren't using printf (there are other printf-like APIs on OS X).  Should we
>> just penalize those developers, who are intentionally writing non-portable
>> code?  I'll admit I'm a bit torn here, but I do know if we just started
>> warning about these without any more intelligence on Clang's part to try and
>> just warn when it makes sense the push back I'd receive from OS X developers
>> would be significant.
> 
> The format checker knows if a string is an objc string literal – it
> already does something different for %S and %C in objc string literals
> (where these mean unichar) than in c string literals (where these mean
> wchar_t, which is usually utf32). So it's possible to have different
> defaults for C string literals and objc string literals.


Ah true.  Point well taken.

The inaccuracies of my example aside, one should not consider this hack as a solution to the more general problem that Joerg pointed out.  There's essentially a family of format specifiers that a function/method may support.  It just so happens we can infer the extended family here by implication of the format string being an Objective-C type, but that's not a hard and fast restriction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120220/77907a36/attachment.html>


More information about the cfe-commits mailing list