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

[James Y Knight via Phabricator via cfe-commits]

jyknight added a comment.

In https://reviews.llvm.org/D42933#1091817, @jfb wrote:

> In https://reviews.llvm.org/D42933#1091809, @jyknight wrote:
>
> > I also think that special casing these two specifiers doesn't make sense. The problem is a general issue -- and one I've often found irritating. This exact same situation comes up all the time in non-Darwin contexts too.
>
>
> I don't think that's true. In this very specific case the platform guarantees that `(sizeof(size_t) == sizeof(NSInteger)) && (sizeof(ssize_t) == sizeof(NSUInteger))` for all architectures this platform supports. This exact same situation does not come up all the time in other contexts because the `int` / `long` / `long long` distinction isn't backed by a portability guarantee. The warning is there to say "this code isn't portable!", but in the very specific case of `NSInteger` and `NSUInteger` it is and users rely on it so it cannot be broken. The warning is therefore spurious, users therefore rightly complain.


The printf format specifier warning is not primarily a cross-platform portability checker. And, although in a few limited cases it can act somewhat like one, in general it does not. Take my previous example -- you get no warning on a platform that has int64_t as a typedef for long -- if this feature is to be useful as a portability checker, it should require that you used the PRId64 macro. Or, given `ssize_t x = 0; printf("%ld", x);`, it doesn't tell you to use "%zd" instead if ssize_t is a typedef for long -- although to be portable you ought to.

No, the major usefulness of the printf warning is to tell you that your code is incorrect for the _current_ platform. And //most// importantly when you chose the wrong size for your argument.

Those types which have matched size and alignment are still different types, and so it's technically appropriate to warn about using the wrong specifier there, too. But it's also entirely reasonable to not want to be bothered by such useless trivia, so skipping the warning when there's only a technical and not actual mismatch seems entirely sensible. (I might suggest that it should even be the default behavior for the warning, and if you want the stricter checks you'd ask for them...but I bet I'll get more pushback on that...)


Repository:
  rC Clang

https://reviews.llvm.org/D42933