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