On Mon, Feb 20, 2012 at 12:05 PM, Ted Kremenek <[email protected]> wrote: > On Feb 20, 2012, at 11:51 AM, Joerg Sonnenberger <[email protected]> > 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
