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

Tue May 8 12:30:48 PDT 2018

jyknight added a comment.

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

> In https://reviews.llvm.org/D42933#1090286, @smeenai wrote:
>
> > I'd be fine with adding an option to relax the printf checking if the size and alignment of the specifier and the actual type match, even if the types themselves differ (`-Wformat-relaxed` or something similar), so that you'd still get warnings on cases where the specifier mismatch could cause runtime issues.
>
>
> What are the cases that you're worried about? The only ones I'm trying to capture here are `NSInteger` with `%zd` and `NSUInteger` with `%zu`, are there others?
>
> > I think that would be preferable to special-casing the Apple types.
>
> If there are more that should be captured and a similar point solution doesn't apply, agreed. However I'd like to understand if we agree on the guarantees that the platform offers for the two specific cases I'm targeting.

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.

E.g. one I find particularly annoying is "%lld" vs "%ld" in printf.

Some 64-bit platforms define e.g. `int64_t` as `long long`, and others as `long`. Although both types are size 8, align 8, and mean exactly the same thing, they are still distinct. And so, users write code like `int64_t x = 0; printf("%ld", x);`...which then emits warnings on the platform that defines int64_t as a `long long`. Obviously, the code _could_ be using `PRId64` instead...but it often doesn't. So it'd sure be nice if you could restrict the warning to only warn about actual problems, and suppress these superficially-incompatible-but-not-really warnings.

So, +1 from me for the general-purpose `-Wformat-relaxed` flag (or whatever other flag name is appropriate).

Repository:
  rC Clang

https://reviews.llvm.org/D42933