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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
