[cfe-dev] Relaxing format specifier checks

Aaron Ballman via cfe-dev cfe-dev at lists.llvm.org
Tue May 22 09:11:07 PDT 2018


On Tue, May 22, 2018 at 5:40 AM, Hans Wennborg via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>>> I still maintain that the warning discussed in D42933 is correct. The
>>> problem to be solved is how to "relax" the warning for those who don't
>>> think their code needs to be checked that strictly.
>>
>> I’m not sure I get your point of view. Is it that you don’t think platforms can offer guarantees beyond what the language mandates; you don’t think Darwin offers said guarantees; you think the guarantee Darwin offers is bogus; or you think that in instances where platforms offer these supplemental guarantees the compiler should warn regardless? Or is it something else?
>
> Yes, I think the compiler should warn regardless because the code is
> still technically incorrect, and not just in a
> trailing-comma-after-last-enumerator way, but in a way I think many
> users care about. I think users expect -Wformat to help them get the
> format specifiers right as per the spec.
>
>
>>> But the original problem is that Clang warns on printing NSInteger
>>> with %zd, and having a -Wformat-relaxed or whatever would solve that
>>> for users who don't want to fix their code. What else do you mean
>>> needs fixing?
>>
>> I need to understand the answer to my question above before we can really discuss this, but basically my POV is that a warning about something a platform guarantees will never be an issue shouldn’t be on by default at -Wall, especially if it’s been show to be quite noisy in real-world code. You can opt-in to more warnings with -Wpedantic or other sub-pedantic flags, but you shouldn’t get it out of -Wall.
>
> My point of view is that warning about these details is valuable
> enough to be on by default. I would see it as a great regression if
> Clang stopped warning about printing long with %d on Windows for
> example --- even though the target guarantees that it works and will
> never be an issue. And I also see the value in letting users who don't
> care turn it off.

+1

~Aaron


More information about the cfe-dev mailing list