[cfe-dev] Relaxing format specifier checks

[James Y Knight via cfe-dev]

>
> >> I'm not saying that the recommendation would change, but `long` being
> >> pointer-sized is a pretty universal assumption on Darwin, I'm afraid.
> >
> >
> > In the review I also said I’d update the documentation once this issue is
> > resolved:
> >
> > https://reviews.llvm.org/D42933#1091502
>
> Yes, but maybe that would be an update in the wrong direction? The
> current documented advice of casting to long and printing with %zd
> seems more correct maybe


I think you had a typo there, the actual recommendation is to cast to long
and print with %ld", not %zd.

I agree, changing Apple's documentation to _recommend_ using %zd, with a
mismatched type, would be an unfortunate update. The docs are definitely
more correct as they stand. Using the wrong format specifier for the type
you passed would still be wrong, even on darwin, even though NSInteger and
size_t are always the same size -- if they're different types, they're
different types, and therefore, it's "technically" a mismatched specifier.
That is what the warning is telling you, and it's right about that.

It's not a "false positive", it's just that it's telling you an annoying
detail which (at least in many cases) is arguably not worth spending any
time on fixing.

> In the very specific case of NSInteger and %z on Darwin platforms, do we

> agree there’s no correctness issue? I’m not talking standards correctness,
> > I’m talking “the code does what’s expected”.
>
> But shouldn't the warnings usually hold the code to a higher standard
> than "does what's expected"


Yes, often so. That said, "your code is technically incorrect, but will
work anyways" is of course less important than "your code is very likely to
be busted". Sometimes both are considered useful enough to end up in the
default warnings set. Sometimes not. I think this situation could go either
way. I'm on the "not worth warning by default" side, but, not firmly. Just
having some -Wno* available would be great already.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180518/ad672266/attachment.html>