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
next 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: linkBe 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).