[cfe-dev] Relaxing format specifier checks

[James Y Knight via cfe-dev]

On Thu, May 17, 2018 at 6:58 AM Hans Wennborg via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Wed, May 16, 2018 at 11:52 PM, JF Bastien via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > On May 16, 2018, at 10:41 AM, Shoaib Meenai via cfe-dev
> > <cfe-dev at lists.llvm.org> wrote:
> > The other thing to point out is, I'm dealing with codebases with
> *thousands*
> > of such instances.
> >
> >
> > This is why we care about this as well.
>
> I haven't heard of any issues coming from this internally at Google or
> in Chromium, so while I understand you have more Cocoa code, it can't
> be that *everything* is broken by this.


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.

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.

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 no compiler "misbehavior", of course!)

> We've cleaned up a lot of them (and the clang fix-its do come in handy

> here), but at some point you just hit a wall and decide to go with
> > -Wno-error=format to be able to move forward. I'm trying to avoid
> throwing
> > the baby out with the bathwater here by adding an option to still retain
> > some of the format errors, at least. My plan is to actually go back and
> > clean up the rest of the issues as well, but this would allow us to do
> it in
> > a staged fashion instead of an all-or-nothing.
>
> It sounds like a -Wformat-relaxed variant would serve this approach


Having the relaxation of the warning be opt-in, instead of the default
behavior, would be a possible option.

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180517/912f5314/attachment.html>