smeenai added a subscriber: rsmith. smeenai added a comment. In https://reviews.llvm.org/D42933#1091943, @jyknight wrote:
> In https://reviews.llvm.org/D42933#1091817, @jfb wrote: > > > In https://reviews.llvm.org/D42933#1091809, @jyknight wrote: > > > > > 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. > > > > > > I don't think that's true. In this very specific case the platform > > guarantees that `(sizeof(size_t) == sizeof(NSInteger)) && (sizeof(ssize_t) > > == sizeof(NSUInteger))` for all architectures this platform supports. This > > exact same situation does not come up all the time in other contexts > > because the `int` / `long` / `long long` distinction isn't backed by a > > portability guarantee. The warning is there to say "this code isn't > > portable!", but in the very specific case of `NSInteger` and `NSUInteger` > > it is and users rely on it so it cannot be broken. The warning is therefore > > spurious, users therefore rightly complain. > > > The printf format specifier warning is not primarily a cross-platform > portability checker. And, although in a few limited cases it can act somewhat > like one, in general it does not. Take my previous example -- you get no > warning on a platform that has int64_t as a typedef for long -- if this > feature is to be useful as a portability checker, it should require that you > used the PRId64 macro. Or, given `ssize_t x = 0; printf("%ld", x);`, it > doesn't tell you to use "%zd" instead if ssize_t is a typedef for long -- > although to be portable you ought to. > > No, the major usefulness of the printf warning is to tell you that your code > is incorrect for the _current_ platform. And //most// importantly when you > chose the wrong size for your argument. > > Those types which have matched size and alignment are still different types, > and so it's technically appropriate to warn about using the wrong specifier > there, too. But it's also entirely reasonable to not want to be bothered by > such useless trivia, so skipping the warning when there's only a technical > and not actual mismatch seems entirely sensible. (I might suggest that it > should even be the default behavior for the warning, and if you want the > stricter checks you'd ask for them...but I bet I'll get more pushback on > that...) +1 to everything you said; what are other people's opinions on this? @rsmith perhaps? 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
