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

[Ted Kremenek]

On Feb 20, 2012, at 12:21 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:

>> 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).
> 
> Actually, you are pointing to a bigger bug here. I mentioned it in an
> earlier discussion on the list. At the moment, the GCC attributes for
> format string checking are very course. It is impossible to distinguish
> between syslog(3) format strings and printf(3) format strings for
> example. The former allows '%m', for the latter it is a glibc extension.
> Other APIs like sqlite_mprint are similar -- they allow an extended
> subset of the printf(3) formatting, but they don't provide the same set.
> I am perfectly fine with allowing all kinds of extensions if the
> function is tagged as having those. That would of course still require
> glibc to accept patches to tag printf(3) as
> __attribute__((__format__(__printf__ | __gnuprintf__, 1, 2))) or
> whatever the syntax should look like, but it would work for the other
> users of format strings.

Exactly.  To follow on that thought, it may also be possible to document what extensions a given version of printf supports using similar annotations.  Similarly, for specific targets would consider dropping in such annotations onto printf automatically, while still allowing users to tailor their warnings to warn about using non-portable format string specifiers.  Without these annotations, however, we cannot distinguish between extensions that are definitely not supported and those that may be unsupported but are non-portable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120220/66e04c42/attachment.html>