[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

In https://reviews.llvm.org/D42933#1092077, @smeenai wrote:

> In https://reviews.llvm.org/D42933#1092048, @rjmccall wrote:
>
> > I agree that the format-specifier checker is not intended to be a portability checker.
>


I don't disagree with the original intent, but AFAICT that's exactly the intent of the warning I'd like to get rid of. I'm making a very narrow point: there is no portability problem with the warning I'm specifically trying to silence (using `%z` with `NS[U]Integer` on Darwin). If we decide that `-Wformat` shouldn't emit portability warnings then my point is moot, so let's see if people agree to that. If not, then my point still stands.

>> Any attempt to check portability problems has to account for two things:
>> 
>> - Not all code is intended to be portable.  If you're going to warn about portability problems, you need some way to not annoy programmers who might have good reason to say that they only care about their code running on Linux / macOS / 64-bit / 32-bit / whatever.  Generally this means splitting the portability warning out as a separate warning group.

Right, it seems like recently `-Wformat` went against this, and users aren't thrilled.

>> - There are always established idioms for solving portability problems.  In this case, a certain set of important typedefs from the C standard have been blessed with dedicated format modifiers like "z", but every other typedef in the world has to find some other solution, either by asserting that some existing format is good enough (as NSInteger does) or by introducing a macro that expands to an appropriate format (as some things in POSIX do).  A proper format-portability warning would have to know about all of these conventions (in order to check that e.g. part of the format string came from the right macro), which just seems wildly out-of-scope for a compiler warning.

We could provide a macro for `NS[U]Integer`, but it's been long enough and there's enough existing code with `%z`. Not sure the code churn on user is worth it, if we can instead say "`%z` works".

> Apple's current recommendation for using printf with the NSInteger types is casting to a long, per https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html. Are you suggesting that recommendation would change to using `%zd` instead?

Indeed, I believe that came from https://github.com/llvm-mirror/clang/commit/ec08735e1b6a51c11533311b774bf6336c0a5d63 and I intend to update documentation once the compiler is updated. It's not *wrong*, it's kinda more portable in that it's what you probably want to do if it's not `NS[U]Integer`, but it's more typing and users clearly haven't been following the recommendation (because let's be honest, `%z` is fine).


Repository:
  rC Clang

https://reviews.llvm.org/D42933