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

Ted Kremenek kremenek at apple.com
Mon Feb 20 12:05:41 PST 2012


On Feb 20, 2012, at 11:51 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:

> The default behavior for -Wformat would be "check that the format string
> is standard compliant". I think that's a perfectively sane default and
> if someone wants to use non-standard format extensions, clang tells them
> how to get them.

There's "non-standard" and then there's completely unportable.  Warnings like:

+  // Combining 'L' with an integer conversion specifier.
+  printf("%Li", (long long)42); // expected-warning{{using the length modifier 'L' with the conversion specifier 'i' is non-standard}}
+  printf("%Lo", (long long)42); // expected-warning{{using the length modifier 'L' with the conversion specifier 'o' is non-standard}}

are likely going to just irritate people.  What's the value in that?

> I don't think that the average piece of code written
> nowadays will only ever run on glibc-Linux / *BSD / Mac OSX or any other
> single platform. I do know that the GCC behavior of silently accepting
> them has created hidden bugs.

I agree with you that permissive checking is allowing bugs to creep in.  There's no disagreement here.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120220/96fb4140/attachment.html>


More information about the cfe-commits mailing list