Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Sam James <sam@gentoo.org>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: [PATCH 4/5] object-file: drop oid field from find_cached_object() return value
Date: Sun, 17 Nov 2024 04:10:24 -0500	[thread overview]
Message-ID: <20241117091024.GD3409496@coredump.intra.peff.net> (raw)
In-Reply-To: <20241117090329.GA2341486@coredump.intra.peff.net>

The pretend_object_file() function adds to an array mapping oids to
object contents, which are later retrieved with find_cached_object().
We naturally need to store the oid for each entry, since it's the lookup
key.

But find_cached_object() also returns a hard-coded empty_tree object.
There we don't care about its oid field and instead compare against
the_hash_algo->empty_tree. The oid field is left as all-zeroes.

This all works, but it means that the cached_object struct we return
from find_cached_object() may or may not have a valid oid field, depend
whether it is the hard-coded tree or came from pretend_object_file().

Nobody looks at the field, so there's no bug. But let's future-proof it
by returning only the object contents themselves, not the oid. We'll
continue to call this "struct cached_object", and the array entry
mapping the key to those contents will be a "cached_object_entry".

This would also let us swap out the array for a better data structure
(like a hashmap) if we chose, but there's not much point. The only code
that adds an entry is git-blame, which adds at most a single entry per
process.

Signed-off-by: Jeff King <peff@peff.net>
---
 object-file.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/object-file.c b/object-file.c
index 5fadd470c1..e461e351ca 100644
--- a/object-file.c
+++ b/object-file.c
@@ -317,27 +317,28 @@ int hash_algo_by_length(int len)
  * to write them into the object store (e.g. a browse-only
  * application).
  */
-static struct cached_object {
+static struct cached_object_entry {
 	struct object_id oid;
-	enum object_type type;
-	const void *buf;
-	unsigned long size;
+	struct cached_object {
+		enum object_type type;
+		const void *buf;
+		unsigned long size;
+	} value;
 } *cached_objects;
 static int cached_object_nr, cached_object_alloc;
 
 static struct cached_object *find_cached_object(const struct object_id *oid)
 {
 	static struct cached_object empty_tree = {
-		/* no oid needed; we'll look it up manually based on the_hash_algo */
 		.type = OBJ_TREE,
 		.buf = "",
 	};
 	int i;
-	struct cached_object *co = cached_objects;
+	struct cached_object_entry *co = cached_objects;
 
 	for (i = 0; i < cached_object_nr; i++, co++) {
 		if (oideq(&co->oid, oid))
-			return co;
+			return &co->value;
 	}
 	if (oideq(oid, the_hash_algo->empty_tree))
 		return &empty_tree;
@@ -1850,7 +1851,7 @@ int oid_object_info(struct repository *r,
 int pretend_object_file(void *buf, unsigned long len, enum object_type type,
 			struct object_id *oid)
 {
-	struct cached_object *co;
+	struct cached_object_entry *co;
 	char *co_buf;
 
 	hash_object_file(the_hash_algo, buf, len, type, oid);
@@ -1859,11 +1860,11 @@ int pretend_object_file(void *buf, unsigned long len, enum object_type type,
 		return 0;
 	ALLOC_GROW(cached_objects, cached_object_nr + 1, cached_object_alloc);
 	co = &cached_objects[cached_object_nr++];
-	co->size = len;
-	co->type = type;
+	co->value.size = len;
+	co->value.type = type;
 	co_buf = xmalloc(len);
 	memcpy(co_buf, buf, len);
-	co->buf = co_buf;
+	co->value.buf = co_buf;
 	oidcpy(&co->oid, oid);
 	return 0;
 }
-- 
2.47.0.541.ge258d9a1f8


  parent reply	other threads:[~2024-11-17  9:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-17  2:50 -Wunterminated-string-initialization warning with GCC 15 in object-file.c Sam James
2024-11-17  9:03 ` Jeff King
2024-11-17  9:08   ` [PATCH 1/5] object-file: prefer array-of-bytes initializer for hash literals Jeff King
2024-11-17  9:52     ` René Scharfe
2024-11-18  9:06       ` Jeff King
2024-11-17  9:08   ` [PATCH 2/5] object-file: drop confusing oid initializer of empty_tree struct Jeff King
2024-11-17  9:08   ` [PATCH 3/5] object-file: move empty_tree struct into find_cached_object() Jeff King
2024-11-18  7:40     ` Patrick Steinhardt
2024-11-18  9:17       ` Jeff King
2024-11-17  9:10   ` Jeff King [this message]
2024-11-17  9:14   ` [PATCH 5/5] object-file: inline empty tree and blob literals Jeff King
2024-11-18  7:40     ` Patrick Steinhardt
2024-11-17 16:03   ` -Wunterminated-string-initialization warning with GCC 15 in object-file.c brian m. carlson
2024-11-18  9:19     ` Jeff King
2024-11-18  9:58       ` Sam James
2024-11-18  7:40   ` Patrick Steinhardt
2024-11-18  9:54   ` [PATCH 0/6] -Wunterminated-string-initialization warning + cleanups Jeff King
2024-11-18  9:54     ` [PATCH 1/6] object-file: prefer array-of-bytes initializer for hash literals Jeff King
2024-11-18  9:55     ` [PATCH 2/6] object-file: drop confusing oid initializer of empty_tree struct Jeff King
2024-11-18  9:55     ` [PATCH 3/6] object-file: move empty_tree struct into find_cached_object() Jeff King
2024-11-18  9:55     ` [PATCH 4/6] object-file: drop oid field from find_cached_object() return value Jeff King
2024-11-18  9:55     ` [PATCH 5/6] object-file: treat cached_object values as const Jeff King
2024-11-18  9:55     ` [PATCH 6/6] object-file: inline empty tree and blob literals Jeff King
2024-11-18 10:51     ` [PATCH 0/6] -Wunterminated-string-initialization warning + cleanups Patrick Steinhardt
2024-11-18 12:49       ` 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

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

  git send-email \
    --in-reply-to=20241117091024.GD3409496@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=sam@gentoo.org \
    --cc=sandals@crustytoothpaste.net \
    /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