git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [RFC PATCH 4/5] pack-objects: avoid reading uninitalized data
Date: Wed, 22 Oct 2008 16:31:03 -0400	[thread overview]
Message-ID: <20081022203103.GD4547@coredump.intra.peff.net> (raw)
In-Reply-To: <20081022202810.GA4439@coredump.intra.peff.net>

In the main loop of find_deltas, we do:

  struct object_entry *entry = *list++;
  ...
  if (!*list_size)
	  ...
	  break

Because we look at and increment *list _before_ the check of
list_size, in the very last iteration of the loop we will
look at uninitialized data, and increment the pointer beyond
one past the end of the allocated space. Since we don't
actually do anything with the data until after the check,
this is not a problem in practice.

But since it technically violates the C standard, and
because it provokes a spurious valgrind warning, let's just
move the initialization of entry to a safe place.

This fixes valgrind errors in t5300, t5301, t5302, t303, and
t9400.

Signed-off-by: Jeff King <peff@peff.net>
---
 builtin-pack-objects.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 59c30d1..15b80db 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1375,7 +1375,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
 	array = xcalloc(window, sizeof(struct unpacked));
 
 	for (;;) {
-		struct object_entry *entry = *list++;
+		struct object_entry *entry;
 		struct unpacked *n = array + idx;
 		int j, max_depth, best_base = -1;
 
@@ -1384,6 +1384,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
 			progress_unlock();
 			break;
 		}
+		entry = *list++;
 		(*list_size)--;
 		if (!entry->preferred_base) {
 			(*processed)++;
-- 
1.6.0.2.825.g6d19d

  parent reply	other threads:[~2008-10-22 20:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-22 20:28 [RFC PATCH 0/5] valgrind in test scripts Jeff King
2008-10-22 20:29 ` [RFC PATCH 1/5] add valgrind support " Jeff King
2008-10-22 22:13   ` Johannes Schindelin
2008-10-23  0:14     ` Junio C Hamano
2008-10-23 15:29       ` Jeff King
2008-10-23 15:19     ` Jeff King
2008-10-22 20:30 ` [RFC PATCH 2/5] valgrind: ignore ldso errors Jeff King
2008-10-22 20:30 ` [RFC PATCH 3/5] correct cache_entry allocation Jeff King
2008-10-22 20:31 ` Jeff King [this message]
2008-10-23  1:11   ` [RFC PATCH 4/5] pack-objects: avoid reading uninitalized data Nicolas Pitre
2008-10-23 15:33     ` Jeff King
2008-10-23 16:47       ` Nicolas Pitre
2008-10-22 20:32 ` [RFC PATCH 5/5] fix overlapping memcpy in normalize_absolute_path Jeff King

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=20081022203103.GD4547@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.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 NNTP newsgroup(s).