<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 17, 2018 at 6:58 AM Hans Wennborg via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 16, 2018 at 11:52 PM, JF Bastien via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On May 16, 2018, at 10:41 AM, Shoaib Meenai via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> The other thing to point out is, I'm dealing with codebases with *thousands*<br>
> of such instances.<br>
><br>
><br>
> This is why we care about this as well.<br>
<br>
I haven't heard of any issues coming from this internally at Google or<br>
in Chromium, so while I understand you have more Cocoa code, it can't<br>
be that *everything* is broken by this.</blockquote><div><br></div><div>No, this actually has been a thorn in the side of some people at google, causing a good deal of angst (only for a very small number of people, granted). I'd not truly put the blame on the warning, but rather on printf itself -- and that we're still USING printf (and other functions that ultimately wrap printf) all over the place. The long-term plan is certainly to switch to better APIs. But, it'd be nice to be able to reduce the issue in the meantime.</div><div><br></div><div>The problem we have is that Google has an internal "int64" typedef, which predates the availability of C99 "int64_t". We'd like to eliminate this, and switch everything over to using the standard int64_t. (Well, really we'd've liked to have done that years ago...) However, "int64" is defined as "long long", while "int64_t" is defined as "long" on 64-bit linux. A bunch of printf specifiers all throughout the codebase use %lld. This mismatching type-specifier makes it quite difficult to change the type. Automatically updating all the format strings has not been found to be easy.</div><div><br></div><div>If we could eliminate the warning on mismatch of "%lld" vs "long", on a platform where they're the same, that could make things a whole lot easier. (only if there's<span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> no compiler "misbehavior", of course!)</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> We've cleaned up a lot of them (and the clang fix-its do come in handy</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> here), but at some point you just hit a wall and decide to go with<br>
> -Wno-error=format to be able to move forward. I'm trying to avoid throwing<br>
> the baby out with the bathwater here by adding an option to still retain<br>
> some of the format errors, at least. My plan is to actually go back and<br>
> clean up the rest of the issues as well, but this would allow us to do it in<br>
> a staged fashion instead of an all-or-nothing.<br>
<br>
It sounds like a -Wformat-relaxed variant would serve this approach</blockquote><div><br></div><div>Having the relaxation of the warning be opt-in, instead of the default behavior, would be a possible option.</div><div><br></div><div>Of course, it must only allow mismatches in situations when the resulting code will not cause issues on the current platform. But, my question then becomes: if we know there's no actual issue, why should it be on by default? Is it actually a worthwhile default warning -- what value is it providing?</div><div><br></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">And if we _can't_ guarantee that it's actually safe, then we shouldn't make the change -- neither as a special case for darwin, or even as an optional flag.</span><br></div><div><br></div><div><br></div></div></div>