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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: rjmccall.
aaron.ballman added a subscriber: rjmccall.
aaron.ballman added a comment.

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

> 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.
>
>
> For Darwin platform, yes. That's why this diagnostic should only be squelched for Darwin platforms.


Ah, I missed the fact that you were proposing this only for Darwin.

>>>> 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.
> 
> Hear, hear! I'm happy to fix any such optimization out of their misguided optimism :-)

People used to think the same thing about many other optimizations that had non-local effects, but we've come to learn that these are not uncommon and incredibly hard for users to track down when it happens. Some enterprising soul could lower the call with an undef on the wrongly-typed argument and then who knows what happens. However, it's also reasonable for us to define undefined behavior for a given platform and that sounds like exactly this case.

If we're looking at only a specific change for Darwin, I think it's reasonable to make it to `-Wformat` rather than require `-Wformat-relaxed` (though we may still want to assert that the size and alignment of the underlying type match expectations).

I've added @rjmccall as a reviewer to see what his opinions are on this, but I'm inclined to say this is a reasonable change to make for Darwin targets.


Repository:
  rC Clang

https://reviews.llvm.org/D42933