[cfe-dev] Relaxing format specifier checks

[JF Bastien via cfe-dev]

> On May 22, 2018, at 4:29 PM, Shoaib Meenai <smeenai at fb.com> wrote:
> 
> Based on all the discussion so far, I think the consensus is that we don't want to relax -Wformat by default, but an additional relaxed option would be fine. That works for me (where I can just switch my codebases to use the new warning option), but it wouldn't handle JF Bastien's use case, so he would still want to pursue the relaxations specific to Apple platforms.
>  
> Does that sound reasonable to everyone? I'm not going to be able to get to the -Wformat relaxation myself immediately, since I have more pressing work right now, but it sounds like Apple will be doing their own thing anyway, so I wouldn't be blocking them.

Sounds good, on our side we’re happy with the patch in D42933, so we’ll move the discussion there.
Thanks for pursuing the discussion on cfe-dev!


> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of cfe-dev <cfe-dev at lists.llvm.org>
> Reply-To: Aaron Ballman <aaron at aaronballman.com>
> Date: Tuesday, May 22, 2018 at 9:11 AM
> To: Hans Wennborg <hans at chromium.org>
> Cc: cfe-dev <cfe-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] Relaxing format specifier checks
>  
> On Tue, May 22, 2018 at 5:40 AM, Hans Wennborg via cfe-dev
> <cfe-dev at lists.llvm.org <mailto: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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=0dYR5xovLPt1wdh6qksdtr2KWUuJOTxxssOpCBqh1nU&s=Q3ZVP9aCVOpfSd2uhYH1xfg0kD3Fr-LnVkBWVlakXjU&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=0dYR5xovLPt1wdh6qksdtr2KWUuJOTxxssOpCBqh1nU&s=Q3ZVP9aCVOpfSd2uhYH1xfg0kD3Fr-LnVkBWVlakXjU&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180522/6cf6a197/attachment.html>