Am 24.11.2013 um 05:08 schrieb David Majnemer <[email protected]>:
> We cannot enable this unconditionally. Clang is already doing the same for GNU and Apple extensions. There is not even a check if glibc is actually used or if the target is Darwin, yet glibc / Apple extensions are allowed. > The vast majority of users will not be using ObjFW, allowing %k in all > conditions may hide diagnostics that would be useful. The same is true for GNU and Apple extensions. Yet it was decided to always allow them. And this makes sense: Not having them there would make using them impossible, as Clang would show a warning when using them, even though they are legal. Same problem with ObjFW: When using %k, Clang currently shows a warning, even though in that context, %k is perfectly legal. > It is also a potential problem if POSIX/IEEE Std 1003.1 chose to use 'k'/'K' > for something. The same is true for the GNU and Apple extensions. Theoretically, POSIX could also add %@, thus breaking ObjC format strings for everyone. So, what do you suggest? The only solution I could think of would be this: For __attribute__((format(…))), a type is specified. This is currently printf or __NSString__. I could patch Clang to accept of_printf and __OFString__ and only accept %k for those two. How about that? This would actually allow to just interpret %C and %S differently instead of needing %k/%K - something I'd prefer, because it's unlikely to be bitten by POSIX in the future then. Currently POSIX uses them for wchar_t, but in ObjC mode, unichar is used instead. So I could just use of_unichar_t instead if the type is of_printf or __OFString__. How does that sound for you? -- Jonathan _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
