On Feb 20, 2012, at 12:13 PM, Nico Weber <[email protected]> wrote:
>> 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.
Ah true. Point well taken.
The inaccuracies of my example aside, one should not consider this hack as a
solution to the more general problem that Joerg pointed out. There's
essentially a family of format specifiers that a function/method may support.
It just so happens we can infer the extended family here by implication of the
format string being an Objective-C type, but that's not a hard and fast
restriction.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
