[cfe-commits] r148324 - in /cfe/trunk: include/clang/Sema/Sema.h lib/Sema/SemaChecking.cpp lib/Sema/SemaExprObjC.cpp test/SemaObjC/format-strings-objc.m

[Jean-Daniel Dupas]

Le 30 janv. 2012 à 17:37, Nico Weber a écrit :

> Cool!
> 
> One thing that this warned on in the chromium source was:
> 
> ../../webkit/plugins/npapi/plugin_web_event_converter_mac.mm:213:37:
> error: format specifies type 'wchar_t *' (aka 'wchar_t *') but the
> argument has type 'const WebUChar *' (aka 'const unsigned short *')
> [-Werror,-Wformat]
>       [NSString stringWithFormat:@"%S", key_event.text]);
>                                    ~^   ~~~~~~~~~~~~~~
> 
> It looks like the current %S warning checks if the parameter type is
> wchar_t. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html#//apple_ref/doc/uid/TP40004265
> says that %S is always utf16 (or ucs16, it doesn't say). `man 3
> printf` says %S is for wchar_t, but I guess it refers to the wchar_t
> type that was effective when libc / AppKit was built. On my OS X 10.6
> box, it looks like printf expects a four byte wchar_t, while AppKit
> expects a two byte wchar_t. Since that code snippet above is about
> AppKit, the code is right and the warning is wrong (chromium isn't
> compiled with -fshort-wchar, but AppKit was, and the warning really
> needs to check against the wchar_t type that was used to build the
> library it's talking to).
> 
> Since %S can expect utf32 (lib) or utf16 (AppKit), the %S warning is
> currently fairly useless. %S seems to be an Apple extension, so should
> we just hardcode %S to look for a 32bit type in c strings and for a
> 16bit type in @"" strings?
> Should we disable the warning for %S
> altogether?


I think we should just extends the printf checker to handle %S differently when the format spec is 'NSString' (it already has special handling for %@).

-- Jean-Daniel