public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "anders at kaseorg dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/47901] New: -Wall should not imply -Wformat-zero-length by default
Date: Sat, 26 Feb 2011 09:11:00 -0000	[thread overview]
Message-ID: <bug-47901-4@http.gcc.gnu.org/bugzilla/> (raw)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901

           Summary: -Wall should not imply -Wformat-zero-length by default
           Product: gcc
           Version: 4.5.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: anders@kaseorg.com


There is nothing wrong with printf("") or custom_printf_like_function(foo, "").
 There are plenty of reasons to write such code: for example, when using a
macro that sometimes expands to the empty string, or if
custom_printf_like_function does something else with foo in addition to using
the format string, or if the string is used for something other than printing
and you really just want the empty string there.

gcc/c-format.c contains a comment that says “If the format is an empty string,
this should be counted similarly to the case of extra format arguments.”  But
those are not actually similar.  Extra format arguments clearly indicate that
the code was not written as intended, because the extra arguments could be
removed with no effects; but a zero-length string is there for a reason and
can’t just be removed.

When GCC complains about legitimate empty format strings as soon as -Wall is
turned on, it only leads to frustration with -Wall.  This leads some users to
give up on -Wall altogether, and thus to miss many of the real problems -Wall
would find; and leads others to come up with brain-damaged workarounds like
adding a useless space:
http://git.kernel.org/linus/6f131ce1dfa9b283ddc212df42b015d152c670a5

Can we change -Wformat-zero-length to default to off unless explicitly
requested?

See also:
http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01469.html
http://ewx.livejournal.com/517490.html
http://www.mail-archive.com/qemu-devel@nongnu.org/msg43910.html


             reply	other threads:[~2011-02-26  8:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-26  9:11 anders at kaseorg dot com [this message]
2012-04-07 20:42 ` [Bug c/47901] " manu at gcc dot gnu.org
2012-04-23 19:58 ` joseph at codesourcery dot com
2012-04-23 20:08 ` manu at gcc dot gnu.org
2012-04-23 20:11 ` andersk at mit dot edu
2012-04-23 20:22 ` andersk at mit dot edu
2012-04-23 20:50 ` joseph at codesourcery dot com
2012-04-23 21:31 ` andersk at mit dot edu
2012-04-26 14:19 ` manu at gcc dot gnu.org
2013-12-21 20:01 ` naesten at gmail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-47901-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).