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

[Nico Weber]

On Mon, Feb 20, 2012 at 12:05 PM, Ted Kremenek <kremenek at apple.com> wrote:
> 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.

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.

Nico