Remove unused assignments

PATCH In review Benjamin Kramer 2 participants 3 messages Jun 15, 2016

lore

Share & tools

lore

Benjamin Kramer

author

2016-06-15 22:46 UTC #0 lore raw

PATCH 1/1 Remove unused assignments

These variables were always overwritten or the assigned value was unused:

builtin-diff-tree.c::cmd_diff_tree(): nr_sha1 builtin-for-each-ref.c::opt_parse_sort(): sort_tail builtin-mailinfo.c::decode_header_bq(): in builtin-shortlog.c::insert_one_record(): len connect.c::git_connect(): path imap-send.c::v_issue_imap_cmd(): n pretty.c::pp_user_info(): filler remote::parse_refspec_internal(): llen

Signed-off-by Benjamin Kramer <[email protected]>

---
 builtin-diff-tree.c    |    1 -
 builtin-for-each-ref.c |    1 -
 builtin-mailinfo.c     |    1 -
 builtin-shortlog.c     |    1 -
 connect.c              |    2 +-
 imap-send.c            |    2 +-
 pretty.c               |    1 -
 remote.c               |    2 +-
 8 files changed, 3 insertions(+), 8 deletions(-)

builtin-diff-tree.c +0 -1

index 8ecefd4..79cedb7 100644
@@ -102,7 +102,6 @@ int cmd_diff_tree(int argc, const char **argv, const char *prefix)
 
 	init_revisions(opt, prefix);
 	git_config(git_diff_basic_config, NULL); /* no "diff" UI options */
-	nr_sha1 = 0;
 	opt->abbrev = 0;
 	opt->diff = 1;
 	argc = setup_revisions(argc, argv, opt, NULL);

builtin-for-each-ref.c +0 -1

index e46b7ad..5cbb4b0 100644
@@ -943,7 +943,6 @@ static int opt_parse_sort(const struct option *opt, const char *arg, int unset)
 		return -1;
 
 	*sort_tail = s = xcalloc(1, sizeof(*s));
-	sort_tail = &s->next;
 
 	if (*arg == '-') {
 		s->reverse = 1;

builtin-mailinfo.c +0 -1

index 2789ccd..1eeeb4d 100644
@@ -537,7 +537,6 @@ static int decode_header_bq(struct strbuf *it)
 				 */
 				strbuf_add(&outbuf, in, ep - in);
 			}
-			in = ep;
 		}
 		/* E.g.
 		 * ep : "=?iso-2022-jp?B?GyR...?= foo"

builtin-shortlog.c +0 -1

index badd912..b28091b 100644
@@ -101,7 +101,6 @@ static void insert_one_record(struct shortlog *log,
 	}
 	while (*oneline && isspace(*oneline) && *oneline != '\n')
 		oneline++;
-	len = eol - oneline;
 	format_subject(&subject, oneline, " ");
 	buffer = strbuf_detach(&subject, NULL);

connect.c +1 -1

index 0a35cc1..7636bf9 100644
@@ -504,7 +504,7 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 				  const char *prog, int flags)
 {
 	char *url = xstrdup(url_orig);
-	char *host, *path = url;
+	char *host, *path;
 	char *end;
 	int c;
 	struct child_process *conn;

imap-send.c +1 -1

index cb518eb..8154cb2 100644
@@ -579,7 +579,7 @@ static struct imap_cmd *v_issue_imap_cmd(struct imap_store *ctx,
 			n = socket_write(&imap->buf.sock, cmd->cb.data, cmd->cb.dlen);
 			free(cmd->cb.data);
 			if (n != cmd->cb.dlen ||
-			    (n = socket_write(&imap->buf.sock, "\r\n", 2)) != 2) {
+			    socket_write(&imap->buf.sock, "\r\n", 2) != 2) {
 				free(cmd->cmd);
 				free(cmd);
 				return NULL;

pretty.c +0 -1

index c018408..3a24cd5 100644
@@ -154,7 +154,6 @@ void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
 		while (line < name_tail && isspace(name_tail[-1]))
 			name_tail--;
 		display_name_length = name_tail - line;
-		filler = "";
 		strbuf_addstr(sb, "From: ");
 		add_rfc2047(sb, line, display_name_length, encoding);
 		strbuf_add(sb, name_tail, namelen - display_name_length);

remote.c +1 -1

index d7079c6..7efaa02 100644
@@ -495,7 +495,7 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
 		int is_glob;
 		const char *lhs, *rhs;
 
-		llen = is_glob = 0;
+		is_glob = 0;
 
 		lhs = refspec[i];
 		if (*lhs == '+') {

Signature · 1 line

1.6.2.169.g92418

Junio C Hamano

2016-06-15 22:46 UTC #1 lore raw

Quoted 12 lines · Benjamin Kramer

These variables were always overwritten or the assigned value was unused:
builtin-diff-tree.c::cmd_diff_tree(): nr_sha1 builtin-for-each-ref.c::opt_parse_sort(): sort_tail builtin-mailinfo.c::decode_header_bq(): in builtin-shortlog.c::insert_one_record(): len connect.c::git_connect(): path imap-send.c::v_issue_imap_cmd(): n pretty.c::pp_user_info(): filler remote::parse_refspec_internal(): llen

Quoted 1 line

Signed-off-by Benjamin Kramer <[email protected]>

Thanks. I eyeballed all of them and they look safe, but this patch made me wonder...

Did you use some dataflow analysis tool to spot these?

It will never scale if a human has to sanity check output from a mechanical process like this patch, especially when the human is already a chokepoint of the whole process (i.e. the maintainer).

We'd need some process improvements in the longer term to handle patches like this, but I do not think of a good one offhand.

I do not think we want to trust tool output blindly; it will not solve the issue to give me the recipe for the mechanical process you used, to have me run it and to make me trust the result without checking. We would want to keep some human whose judgement we can trust in the loop to always check the changes mechanical analysis tools may produce.

I think the only viable long term solution would be to keep doing the manual verification I did like this round until somebody like you accumulate enough "trust points" in the community for consistently sending good patches like this one to allow me to apply patches from these people blindly, trusting the sender's judgement.

But please disregard all of the above if you spotted these by manual inspection.

I think the patch to pp_user_info() can go one step further. The filler is used at only one place after this patch, as a strong given to one of the placeholders in strbuf_addf(). We can simply feed a constant to the function instead, like this:

pretty.c +1 -2

index 3a24cd5..efa7024 100644
@@ -135,7 +135,6 @@ void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
 	int namelen;
 	unsigned long time;
 	int tz;
-	const char *filler = "    ";
 
 	if (fmt == CMIT_FMT_ONELINE)
 		return;

@@ -161,7 +160,7 @@ void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
 	} else {
 		strbuf_addf(sb, "%s: %.*s%.*s\n", what,
 			      (fmt == CMIT_FMT_FULLER) ? 4 : 0,
-			      filler, namelen, line);
+			      "    ", namelen, line);
 	}
 	switch (fmt) {
 	case CMIT_FMT_MEDIUM:

Benjamin Kramer

author

2016-06-15 22:46 UTC #2 lore raw

Quoted 9 lines · Junio C Hamano

Thanks. I eyeballed all of them and they look safe, but this patch made me wonder...
Did you use some dataflow analysis tool to spot these?
It will never scale if a human has to sanity check output from a mechanical process like this patch, especially when the human is already a chokepoint of the whole process (i.e. the maintainer).

Yep, they were found with a little help of the clang static analyzer

http://clang.llvm.org/StaticAnalysis.html

It is in early stages of development so it may report false positives and it chokes on some files. Here is the latest output I have, with my patch applied:

http://doktorz.mooltied.de/stuff/scan-build-2009-03-13-2/

I've looked briefly at the "Logic Errors" and they all seem to be false positives. I did not have enough time to look into all the remaining "Dead Stores" though.

-- Benjamin