git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: git@vger.kernel.org
Cc: Eric Sunshine <sunshine@sunshineco.com>,
	Junio C Hamano <gitster@pobox.com>, Toon Claes <toon@iotcl.com>,
	Karthik Nayak <karthik.188@gmail.com>
Subject: [PATCH v3 9/9] reftable/record: improve semantics when initializing records
Date: Tue, 6 Feb 2024 07:35:59 +0100	[thread overview]
Message-ID: <5bb2858c1366367e293ca81838c08b643420026b.1707200355.git.ps@pks.im> (raw)
In-Reply-To: <cover.1707200355.git.ps@pks.im>

[-- Attachment #1: Type: text/plain, Size: 7146 bytes --]

According to our usual coding style, the `reftable_new_record()`
function would indicate that it is allocating a new record. This is not
the case though as the function merely initializes records without
allocating any memory.

Replace `reftable_new_record()` with a new `reftable_record_init()`
function that takes a record pointer as input and initializes it
accordingly.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 reftable/block.c       | 18 +++++++++---------
 reftable/merged.c      |  8 +++++---
 reftable/reader.c      |  4 ++--
 reftable/record.c      | 43 ++++++++++--------------------------------
 reftable/record.h      | 10 +++++-----
 reftable/record_test.c |  4 ++--
 6 files changed, 33 insertions(+), 54 deletions(-)

diff --git a/reftable/block.c b/reftable/block.c
index 838759823a..ce8a7d24f3 100644
--- a/reftable/block.c
+++ b/reftable/block.c
@@ -382,23 +382,23 @@ int block_reader_seek(struct block_reader *br, struct block_iter *it,
 		.key = *want,
 		.r = br,
 	};
-	struct reftable_record rec = reftable_new_record(block_reader_type(br));
-	int err = 0;
 	struct block_iter next = BLOCK_ITER_INIT;
+	struct reftable_record rec;
+	int err = 0, i;
 
-	int i = binsearch(br->restart_count, &restart_key_less, &args);
 	if (args.error) {
 		err = REFTABLE_FORMAT_ERROR;
 		goto done;
 	}
 
-	it->br = br;
-	if (i > 0) {
-		i--;
-		it->next_off = block_reader_restart_offset(br, i);
-	} else {
+	i = binsearch(br->restart_count, &restart_key_less, &args);
+	if (i > 0)
+		it->next_off = block_reader_restart_offset(br, i - 1);
+	else
 		it->next_off = br->header_off + 4;
-	}
+	it->br = br;
+
+	reftable_record_init(&rec, block_reader_type(br));
 
 	/* We're looking for the last entry less/equal than the wanted key, so
 	   we have to go one entry too far and then back up.
diff --git a/reftable/merged.c b/reftable/merged.c
index 0e60e2a39b..a0f222e07b 100644
--- a/reftable/merged.c
+++ b/reftable/merged.c
@@ -21,11 +21,11 @@ static int merged_iter_init(struct merged_iter *mi)
 {
 	for (size_t i = 0; i < mi->stack_len; i++) {
 		struct pq_entry e = {
-			.rec = reftable_new_record(mi->typ),
 			.index = i,
 		};
 		int err;
 
+		reftable_record_init(&e.rec, mi->typ);
 		err = iterator_next(&mi->stack[i], &e.rec);
 		if (err < 0)
 			return err;
@@ -57,10 +57,12 @@ static int merged_iter_advance_nonnull_subiter(struct merged_iter *mi,
 					       size_t idx)
 {
 	struct pq_entry e = {
-		.rec = reftable_new_record(mi->typ),
 		.index = idx,
 	};
-	int err = iterator_next(&mi->stack[idx], &e.rec);
+	int err;
+
+	reftable_record_init(&e.rec, mi->typ);
+	err = iterator_next(&mi->stack[idx], &e.rec);
 	if (err < 0)
 		return err;
 
diff --git a/reftable/reader.c b/reftable/reader.c
index 3e0de5e8ad..5e6c8f30a1 100644
--- a/reftable/reader.c
+++ b/reftable/reader.c
@@ -444,13 +444,13 @@ static int reader_start(struct reftable_reader *r, struct table_iter *ti,
 static int reader_seek_linear(struct table_iter *ti,
 			      struct reftable_record *want)
 {
-	struct reftable_record rec =
-		reftable_new_record(reftable_record_type(want));
 	struct strbuf want_key = STRBUF_INIT;
 	struct strbuf got_key = STRBUF_INIT;
 	struct table_iter next = TABLE_ITER_INIT;
+	struct reftable_record rec;
 	int err = -1;
 
+	reftable_record_init(&rec, reftable_record_type(want));
 	reftable_record_key(want, &want_key);
 
 	while (1) {
diff --git a/reftable/record.c b/reftable/record.c
index 2f3cd6b62c..26c5e43f9b 100644
--- a/reftable/record.c
+++ b/reftable/record.c
@@ -1259,45 +1259,22 @@ reftable_record_vtable(struct reftable_record *rec)
 	abort();
 }
 
-struct reftable_record reftable_new_record(uint8_t typ)
+void reftable_record_init(struct reftable_record *rec, uint8_t typ)
 {
-	struct reftable_record clean = {
-		.type = typ,
-	};
+	memset(rec, 0, sizeof(*rec));
+	rec->type = typ;
 
-	/* the following is involved, but the naive solution (just return
-	 * `clean` as is, except for BLOCK_TYPE_INDEX), returns a garbage
-	 * clean.u.obj.offsets pointer on Windows VS CI.  Go figure.
-	 */
 	switch (typ) {
-	case BLOCK_TYPE_OBJ:
-	{
-		struct reftable_obj_record obj = { 0 };
-		clean.u.obj = obj;
-		break;
-	}
-	case BLOCK_TYPE_INDEX:
-	{
-		struct reftable_index_record idx = {
-			.last_key = STRBUF_INIT,
-		};
-		clean.u.idx = idx;
-		break;
-	}
 	case BLOCK_TYPE_REF:
-	{
-		struct reftable_ref_record ref = { 0 };
-		clean.u.ref = ref;
-		break;
-	}
 	case BLOCK_TYPE_LOG:
-	{
-		struct reftable_log_record log = { 0 };
-		clean.u.log = log;
-		break;
-	}
+	case BLOCK_TYPE_OBJ:
+		return;
+	case BLOCK_TYPE_INDEX:
+		strbuf_init(&rec->u.idx.last_key, 0);
+		return;
+	default:
+		BUG("unhandled record type");
 	}
-	return clean;
 }
 
 void reftable_record_print(struct reftable_record *rec, int hash_size)
diff --git a/reftable/record.h b/reftable/record.h
index fd80cd451d..e64ed30c80 100644
--- a/reftable/record.h
+++ b/reftable/record.h
@@ -69,9 +69,6 @@ struct reftable_record_vtable {
 /* returns true for recognized block types. Block start with the block type. */
 int reftable_is_block_type(uint8_t typ);
 
-/* return an initialized record for the given type */
-struct reftable_record reftable_new_record(uint8_t typ);
-
 /* Encode `key` into `dest`. Sets `is_restart` to indicate a restart. Returns
  * number of bytes written. */
 int reftable_encode_key(int *is_restart, struct string_view dest,
@@ -100,8 +97,8 @@ struct reftable_obj_record {
 /* record is a generic wrapper for different types of records. It is normally
  * created on the stack, or embedded within another struct. If the type is
  * known, a fresh instance can be initialized explicitly. Otherwise, use
- * reftable_new_record() to initialize generically (as the index_record is not
- * valid as 0-initialized structure)
+ * `reftable_record_init()` to initialize generically (as the index_record is
+ * not valid as 0-initialized structure)
  */
 struct reftable_record {
 	uint8_t type;
@@ -113,6 +110,9 @@ struct reftable_record {
 	} u;
 };
 
+/* Initialize the reftable record for the given type */
+void reftable_record_init(struct reftable_record *rec, uint8_t typ);
+
 /* see struct record_vtable */
 int reftable_record_equal(struct reftable_record *a, struct reftable_record *b, int hash_size);
 void reftable_record_print(struct reftable_record *rec, int hash_size);
diff --git a/reftable/record_test.c b/reftable/record_test.c
index 999366ad46..a86cff5526 100644
--- a/reftable/record_test.c
+++ b/reftable/record_test.c
@@ -16,11 +16,11 @@
 
 static void test_copy(struct reftable_record *rec)
 {
-	struct reftable_record copy = { 0 };
+	struct reftable_record copy;
 	uint8_t typ;
 
 	typ = reftable_record_type(rec);
-	copy = reftable_new_record(typ);
+	reftable_record_init(&copy, typ);
 	reftable_record_copy_from(&copy, rec, GIT_SHA1_RAWSZ);
 	/* do it twice to catch memory leaks */
 	reftable_record_copy_from(&copy, rec, GIT_SHA1_RAWSZ);
-- 
2.43.GIT


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2024-02-06  6:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31  8:00 [PATCH 0/9] reftable: code style improvements Patrick Steinhardt
2024-01-31  8:01 ` [PATCH 1/9] reftable: introduce macros to grow arrays Patrick Steinhardt
2024-01-31 17:44   ` Eric Sunshine
2024-01-31 20:35   ` Junio C Hamano
2024-02-01  7:29     ` Patrick Steinhardt
2024-02-01 16:30       ` Junio C Hamano
2024-01-31  8:01 ` [PATCH 2/9] reftable: introduce macros to allocate arrays Patrick Steinhardt
2024-01-31  8:01 ` [PATCH 3/9] reftable/stack: fix parameter validation when compacting range Patrick Steinhardt
2024-01-31  8:01 ` [PATCH 4/9] reftable/stack: index segments with `size_t` Patrick Steinhardt
2024-01-31  8:01 ` [PATCH 5/9] reftable/stack: use `size_t` to track stack slices during compaction Patrick Steinhardt
2024-01-31  8:01 ` [PATCH 6/9] reftable/stack: use `size_t` to track stack length Patrick Steinhardt
2024-01-31  8:01 ` [PATCH 7/9] reftable/merged: refactor seeking of records Patrick Steinhardt
2024-01-31 17:55   ` Eric Sunshine
2024-01-31  8:01 ` [PATCH 8/9] reftable/merged: refactor initialization of iterators Patrick Steinhardt
2024-01-31  8:01 ` [PATCH 9/9] reftable/record: improve semantics when initializing records Patrick Steinhardt
2024-02-01  7:32 ` [PATCH v2 0/9] reftable: code style improvements Patrick Steinhardt
2024-02-01  7:32   ` [PATCH v2 1/9] reftable: introduce macros to grow arrays Patrick Steinhardt
2024-02-01  7:32   ` [PATCH v2 2/9] reftable: introduce macros to allocate arrays Patrick Steinhardt
2024-02-05 15:48     ` Karthik Nayak
2024-02-06  6:10       ` Patrick Steinhardt
2024-02-01  7:33   ` [PATCH v2 3/9] reftable/stack: fix parameter validation when compacting range Patrick Steinhardt
2024-02-01 16:15     ` Toon Claes
2024-02-02  5:21       ` Patrick Steinhardt
2024-02-01  7:33   ` [PATCH v2 4/9] reftable/stack: index segments with `size_t` Patrick Steinhardt
2024-02-01  7:33   ` [PATCH v2 5/9] reftable/stack: use `size_t` to track stack slices during compaction Patrick Steinhardt
2024-02-01  7:33   ` [PATCH v2 6/9] reftable/stack: use `size_t` to track stack length Patrick Steinhardt
2024-02-01  7:33   ` [PATCH v2 7/9] reftable/merged: refactor seeking of records Patrick Steinhardt
2024-02-01  7:33   ` [PATCH v2 8/9] reftable/merged: refactor initialization of iterators Patrick Steinhardt
2024-02-01  7:33   ` [PATCH v2 9/9] reftable/record: improve semantics when initializing records Patrick Steinhardt
2024-02-06  6:35 ` [PATCH v3 0/9] reftable: code style improvements Patrick Steinhardt
2024-02-06  6:35   ` [PATCH v3 1/9] reftable: introduce macros to grow arrays Patrick Steinhardt
2024-02-06  6:35   ` [PATCH v3 2/9] reftable: introduce macros to allocate arrays Patrick Steinhardt
2024-02-06  6:35   ` [PATCH v3 3/9] reftable/stack: fix parameter validation when compacting range Patrick Steinhardt
2024-02-06  6:35   ` [PATCH v3 4/9] reftable/stack: index segments with `size_t` Patrick Steinhardt
2024-02-06  6:35   ` [PATCH v3 5/9] reftable/stack: use `size_t` to track stack slices during compaction Patrick Steinhardt
2024-02-06  6:35   ` [PATCH v3 6/9] reftable/stack: use `size_t` to track stack length Patrick Steinhardt
2024-02-06  6:35   ` [PATCH v3 7/9] reftable/merged: refactor seeking of records Patrick Steinhardt
2024-02-06  6:35   ` [PATCH v3 8/9] reftable/merged: refactor initialization of iterators Patrick Steinhardt
2024-02-06  6:35   ` Patrick Steinhardt [this message]
2024-02-06  9:10   ` [PATCH v3 0/9] reftable: code style improvements Karthik Nayak

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=5bb2858c1366367e293ca81838c08b643420026b.1707200355.git.ps@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=toon@iotcl.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.
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).