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

Tue May 8 08:52:15 PDT 2018

smeenai added a comment.

In https://reviews.llvm.org/D42933#1091234, @aaron.ballman wrote:

> In https://reviews.llvm.org/D42933#1090268, @jfb wrote:
>
> > I was just looking at this, and I think @arphaman's patch is pretty much the right approach (with 2 suggested fixes below).
> >
> > I don't think the code we're currently warning on is broken: a user code has `NSInteger` with `%zd` or `NSUInteger` with `%zu`, and on all platforms which support those types the implementor has guaranteed that `(sizeof(size_t) == sizeof(NSInteger)) && (sizeof(ssize_t) == sizeof(NSUInteger))`.
>
>
> Yes, but is this guaranteed to be the case or does it happen to be the case? I'm worried about the less mainstream uses where you might find ObjC code where this does not hold but -Wformat points out a portability concern.

Also keep in mind that Obj-C might be used on non-Apple platforms, e.g. there's an active review going on for GNUstep ABI v2 right now (https://reviews.llvm.org/D46052), and WinObjC is also a thing. Those platforms might not necessarily provide the same guarantees or consistency that Apple's do.

>> I agree that, if we're playing C++ pedant and look at the typedefs, then it's undefined behavior and the code is broken.
> 
> This is reason alone to diagnose the code, because the optimizer is welcome to use that UB to perform transformations the programmer did not expect. However, I'm not certain our optimizer is currently paying attention to that UB directly, so this may not be an immediate issue (but could be a pitfall for the future) but I'm not certain about other optimizers for which portability would still be a concern.

I would honestly find it a bit surprising (and scary) if the optimizer actually took advantage of UB in the case where the size and alignment of the specifier and the actual type matches.

Repository:
  rC Clang

https://reviews.llvm.org/D42933