aaron.ballman added a comment. In https://reviews.llvm.org/D47290#1124991, @hans wrote:
> In https://reviews.llvm.org/D47290#1124964, @aaron.ballman wrote: > > > In https://reviews.llvm.org/D47290#1124956, @hans wrote: > > > > > In https://reviews.llvm.org/D47290#1124933, @aaron.ballman wrote: > > > > > > > In https://reviews.llvm.org/D47290#1124866, @hans wrote: > > > > > > > > > If we really want to special-case NSInteger, and given that you're > > > > > targeting a specific wide-spread pattern maybe that's the right thing > > > > > to do, I think we should make -Wformat accept (move the warning > > > > > behind -Wformat-pedantic I suppose) printing NSInteger with *any* > > > > > integral type of the right size, not just size_t. > > > > > > > > > > > > Would you be similarly okay with %ld and %d on Windows platforms when > > > > mixing up int and long? > > > > > > > > > No, I'm against a general relaxation of -Wformat, but to solve JF's > > > problem I think special-casing NSInteger might be reasonable. > > > > > > How is JF's problem different? > > > It concerns a vendor-specific type. Of course I personally think it would be > better if the code could be fixed, but it doesn't sound like that's an option > so then I think special-casing for NSInteger is an acceptable solution. Okay, that's fair, but the vendor-specific type for my Windows example is spelled `DWORD`. I'm really worried that this special case will become a precedent and we'll wind up with -Wformat being relaxed for everything based on the same rationale. If that's how the community wants -Wformat to work, cool, but I'd like to know if we're intending to change (what I see as) the design of this warning. Repository: rC Clang https://reviews.llvm.org/D47290 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
