git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Ralf Thielow via GitGitGadget <gitgitgadget@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Alban Gruin <alban.gruin@gmail.com>,
	Ralf Thielow <ralf.thielow@gmail.com>
Subject: [PATCH] config.mak.dev: re-enable -Wformat-zero-length
Date: Thu, 27 Feb 2020 18:54:45 -0500	[thread overview]
Message-ID: <20200227235445.GA1371170@coredump.intra.peff.net> (raw)
In-Reply-To: <pull.567.git.1582835130592.gitgitgadget@gmail.com>

On Thu, Feb 27, 2020 at 08:25:30PM +0000, Ralf Thielow via GitGitGadget wrote:

> Fixes the following warnings:
> 
> rebase-interactive.c: In function ‘edit_todo_list’:
> rebase-interactive.c:137:38: warning: zero-length gnu_printf format string [-Wformat-zero-length]
>     write_file(rebase_path_dropped(), "");
> rebase-interactive.c:144:37: warning: zero-length gnu_printf format string [-Wformat-zero-length]
>    write_file(rebase_path_dropped(), "");

Thanks, I think this is worth doing.

I had noticed them, too, but then they "went away" so I assumed they had
already been fixed. It turns out that it's the difference between a
build with and without the DEVELOPER Makefile knob set.

I think we should do this on top:

-- >8 --
Subject: [PATCH] config.mak.dev: re-enable -Wformat-zero-length

We recently triggered some -Wformat-zero-length warnings in the code,
but no developers noticed because we suppress that warning in builds
with the DEVELOPER=1 Makefile knob set. But we _don't_ suppress them in
a non-developer build (and they're part of -Wall). So even though
non-developers probably aren't using -Werror, they see the annoying
warnings when they build.

We've had back and forth discussion over the years on whether this
warning is useful or not. In most cases we've seen, it's not true that
the call is a mistake, since we're using its side effects (like adding a
newline status_printf_ln()) or writing an empty string to a destination
which is handled by the function (as in write_file()). And so we end up
working around it in the source by passing ("%s", "").

There's more discussion in the subthread starting at:

  https://lore.kernel.org/git/xmqqtwaod7ly.fsf@gitster.mtv.corp.google.com/

The short of it is that we probably can't just disable the warning for
everybody because of portability issues. And ignoring it for developers
puts us in the situation we're in now, where non-dev builds are annoyed.

Since the workaround is both rarely needed and fairly straight-forward,
let's just commit to doing it as necessary, and re-enable the warning.

Signed-off-by: Jeff King <peff@peff.net>
---
I had totally forgotten about that thread until researching the history
just now. There's another option there involving #pragma, but it was too
gross for me to even suggest now as an alternative in the commit
message. ;) I think this is the most practical improvement.

 config.mak.dev | 1 -
 1 file changed, 1 deletion(-)

diff --git a/config.mak.dev b/config.mak.dev
index bf1f3fcdee..89b218d11a 100644
--- a/config.mak.dev
+++ b/config.mak.dev
@@ -9,7 +9,6 @@ endif
 DEVELOPER_CFLAGS += -Wall
 DEVELOPER_CFLAGS += -Wdeclaration-after-statement
 DEVELOPER_CFLAGS += -Wformat-security
-DEVELOPER_CFLAGS += -Wno-format-zero-length
 DEVELOPER_CFLAGS += -Wold-style-definition
 DEVELOPER_CFLAGS += -Woverflow
 DEVELOPER_CFLAGS += -Wpointer-arith
-- 
2.25.1.911.g022f5304bc


  reply	other threads:[~2020-02-27 23:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 20:25 [PATCH] rebase-interactive.c: silence format-zero-length warnings Ralf Thielow via GitGitGadget
2020-02-27 23:54 ` Jeff King [this message]
2020-02-28 16:42   ` [PATCH] config.mak.dev: re-enable -Wformat-zero-length Junio C Hamano
2020-02-28 17:06     ` Jeff King
2020-03-03 10:17 ` [PATCH] rebase-interactive.c: silence format-zero-length warnings Alban Gruin
2020-03-03 14:20   ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20200227235445.GA1371170@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=alban.gruin@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=ralf.thielow@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).