git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <stefanbeller@googlemail.com>
Cc: peff@peff.net, git@vger.kernel.org
Subject: Re: [PATCH] status_printf_ln: Suppress false positive warnings of empty format string.
Date: Fri, 19 Jul 2013 09:01:28 -0700	[thread overview]
Message-ID: <7v7ggmy1wn.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1374242889-14239-1-git-send-email-stefanbeller@googlemail.com> (Stefan Beller's message of "Fri, 19 Jul 2013 16:08:09 +0200")

Stefan Beller <stefanbeller@googlemail.com> writes:

> This is a response to 8dd0ee823f1829a3aa228c3c73e31de5c89b5317.
>
> Instead of having an empty string as format for the printf like function
> status_printf_ln, we could insert an empty string into the format
> parameter.
>
> A similar fixup commit is found in linux (2e4c332913b5), but there
> the empty string is replaced by a string containing one whitespace.
>
> To determine, which approach is better I setup 2 test programs, which
> either have a whitespace format (" ") or the empty string ("%s", ""),
> looking like:
> -
> 	#include <stdlib.h>
> 	#include <stdio.h>
> 	int main (int argc, char** argv) {
> 		long i;
> 		for (i = 0; i < 1024*1024*1024; ++i)
> 			printf(" ");
> 	}
> -
> Checking the required time of the programs, while redirecting the actual
> output (the billion white spaces compared to nothing) to /dev/null
> indicates that the approach used in this patch is faster regardless
> of the optimization level of gcc.
>
> Also this patch doesn't change output, which favors this approach over
> the whitespace approach.

Even if the " " variant is faster, it does not matter if its output
is incorrect ;-)

> The only thing left to discuss, whether this patch is worth it, as it
> only suppresses false positive warnings from gcc, but makes the
> code slightly harder to read.

I think we discussed this already?  The conclusion was it is silly
for GCC to warn on -Wformat-zero-length for user-defined function in
the first place, IIRC.  func(other, args, fmt,...), when invoked as
func(other, args, ""), may very well do something useful regardless
of the formatting part based on other args.

For that matter, I personally think -Wformat-zero-length warning for
standard ones, like

	printf("");

is silly, too.  It is not like

	printf("", extra, arg);

is not caught as an error.

So we can just add -Wno-format-zero-length after -Wall and be done
with it?

>
> Signed-off-by: Stefan Beller <stefanbeller@googlemail.com>
> ---
>  builtin/commit.c |  2 +-
>  wt-status.c      | 18 +++++++++---------
>  2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 65cf2a7..34bc274 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -773,7 +773,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
>  				committer_ident.buf);
>  
>  		if (ident_shown)
> -			status_printf_ln(s, GIT_COLOR_NORMAL, "");
> +			status_printf_ln(s, GIT_COLOR_NORMAL, "%s", "");
>  
>  		saved_color_setting = s->use_color;
>  		s->use_color = 0;
> diff --git a/wt-status.c b/wt-status.c
> index cb24f1f..912ed88 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -179,7 +179,7 @@ static void wt_status_print_unmerged_header(struct wt_status *s)
>  	} else {
>  		status_printf_ln(s, c, _("  (use \"git add/rm <file>...\" as appropriate to mark resolution)"));
>  	}
> -	status_printf_ln(s, c, "");
> +	status_printf_ln(s, c, "%s", "");
>  }
>  
>  static void wt_status_print_cached_header(struct wt_status *s)
> @@ -195,7 +195,7 @@ static void wt_status_print_cached_header(struct wt_status *s)
>  		status_printf_ln(s, c, _("  (use \"git reset %s <file>...\" to unstage)"), s->reference);
>  	else
>  		status_printf_ln(s, c, _("  (use \"git rm --cached <file>...\" to unstage)"));
> -	status_printf_ln(s, c, "");
> +	status_printf_ln(s, c, "%s", "");
>  }
>  
>  static void wt_status_print_dirty_header(struct wt_status *s,
> @@ -214,7 +214,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,
>  	status_printf_ln(s, c, _("  (use \"git checkout -- <file>...\" to discard changes in working directory)"));
>  	if (has_dirty_submodules)
>  		status_printf_ln(s, c, _("  (commit or discard the untracked or modified content in submodules)"));
> -	status_printf_ln(s, c, "");
> +	status_printf_ln(s, c, "%s", "");
>  }
>  
>  static void wt_status_print_other_header(struct wt_status *s,
> @@ -226,12 +226,12 @@ static void wt_status_print_other_header(struct wt_status *s,
>  	if (!advice_status_hints)
>  		return;
>  	status_printf_ln(s, c, _("  (use \"git %s <file>...\" to include in what will be committed)"), how);
> -	status_printf_ln(s, c, "");
> +	status_printf_ln(s, c, "%s", "");
>  }
>  
>  static void wt_status_print_trailer(struct wt_status *s)
>  {
> -	status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
> +	status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
>  }
>  
>  #define quote_path quote_path_relative
> @@ -1192,7 +1192,7 @@ void wt_status_print(struct wt_status *s)
>  				on_what = _("Not currently on any branch.");
>  			}
>  		}
> -		status_printf(s, color(WT_STATUS_HEADER, s), "");
> +		status_printf(s, color(WT_STATUS_HEADER, s), "%s", "");
>  		status_printf_more(s, branch_status_color, "%s", on_what);
>  		status_printf_more(s, branch_color, "%s\n", branch_name);
>  		if (!s->is_initial)
> @@ -1205,9 +1205,9 @@ void wt_status_print(struct wt_status *s)
>  	free(state.detached_from);
>  
>  	if (s->is_initial) {
> -		status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
> +		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
>  		status_printf_ln(s, color(WT_STATUS_HEADER, s), _("Initial commit"));
> -		status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
> +		status_printf_ln(s, color(WT_STATUS_HEADER, s), "%s", "");
>  	}
>  
>  	wt_status_print_updated(s);
> @@ -1224,7 +1224,7 @@ void wt_status_print(struct wt_status *s)
>  		if (s->show_ignored_files)
>  			wt_status_print_other(s, &s->ignored, _("Ignored files"), "add -f");
>  		if (advice_status_u_option && 2000 < s->untracked_in_ms) {
> -			status_printf_ln(s, GIT_COLOR_NORMAL, "");
> +			status_printf_ln(s, GIT_COLOR_NORMAL, "%s", "");
>  			status_printf_ln(s, GIT_COLOR_NORMAL,
>  					 _("It took %.2f seconds to enumerate untracked files. 'status -uno'\n"
>  					   "may speed it up, but you have to be careful not to forget to add\n"

  reply	other threads:[~2013-07-19 16:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-19 14:08 [PATCH] status_printf_ln: Suppress false positive warnings of empty format string Stefan Beller
2013-07-19 16:01 ` Junio C Hamano [this message]
2013-07-19 16:04   ` Stefan Beller

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=7v7ggmy1wn.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=stefanbeller@googlemail.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).