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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to