Re: [PATCH] wt-status.c: disable those distracting -Wformat-zero-length warnings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Dec 21, 2013 at 4:42 AM, Jeff King <peff@xxxxxxxx> wrote:
> On Fri, Dec 20, 2013 at 10:45:01AM -0500, Samuel Bronson wrote:
>
>> These warnings don't really seem to make much sense for this file.
>
> Agreed, though the advice so far has been to put -Wno-format-zero-length
> in your CFLAGS.

Yes, auto-detecting acceptance of this flag and using it automatically
might be a reasonable approach as well, but I thought this warning
might potentially be useful WRT other printf-like functions.

>> +/* We have good reasons for using zero-length format strings, and
>> + * there's unfortunately no way to turn this off on a per-function
>> + * basis ... */
>> +#pragma GCC diagnostic ignored "-Wformat-zero-length"
>
> Are other compilers happy to ignore this pragma? I guess we could wrap
> it in an #ifdef, if so.

I assume you meant we could use an #ifdef if *not*?

> It's also really not about this file in particular. The whole concept of
> format-zero-length is questionable, as it ignores the concept that a
> format function might actually do something useful with an empty format
> (e.g., by adding boilerplate, or having a side-effect). It's just that
> this file is the only one that happens to do so.

Hmm, I think I saw one other instance of this warning, actually, but
it didn't seem worth adding the pragma to a file for just one warning.

> Annotating the _function_ to say "it's useful to pass an empty format
> into this function" would make sense, but as you note, there is no way
> to do that.

I made a note about this at
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901#c9> (comment #9 on
"-Wall should not imply -Wformat-zero-length by default")

> So I dunno. This seems like it does not quite specify what we want to
> say as well as just "-Wno-format-zero-length", but it is more convenient
> in practice (because we take care of it in the source code, rather than
> relying on the user's build settings).

Yeah.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]