[cfe-dev] Relaxing format specifier checks

Hans Wennborg via cfe-dev cfe-dev at lists.llvm.org
Tue May 22 02:17:23 PDT 2018


On Fri, May 18, 2018 at 6:37 PM, James Y Knight <jyknight at google.com> wrote:
>> >> 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.

Oops, yes, I meant what you said :-)

> 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.

I really appreciate when the compiler informs me of this kind of
detail. The way I see it, it allows me to worry less about getting the
specifiers right on my own.

>> > 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.

I understand that some users might not care, and that's fine, so
having a -Wno-format-something to suppress it is reasonable, but I
wouldn't want to change the default since I think it's worked well so
far.



More information about the cfe-dev mailing list