reftable/block: store block pointer in the block iterator

The block iterator requires access to a bunch of data from the
underlying `reftable_block` that it is iterating over. This data is
stored by copying over relevant data into a separate set of variables.
This has multiple downsides:

  - We require more storage space than necessary. This is more of a
    theoretical issue as we shouldn't ever have many blocks.

  - We have to perform more bookkeeping, and the variable names are
    inconsistent across the two data structures. This can lead to some
    confusion.

  - The lifetime of the block iterator is tied to the block anyway, but
    we hide that a bit by only storing pointers pointing into the block.

There isn't really any good reason why we rip out parts of the block
instead of storing a pointer to the block itself.

Refactor the code to do so. Despite being simpler, it also allows us to
decouple the lifetime of the block iterator from seeking in a subsequent
commit.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Patrick Steinhardt
2025-04-07 15:16:22 +02:00
committed by Junio C Hamano
parent 655e18d6b4
commit 156d79cef0
2 changed files with 9 additions and 17 deletions

View File

@@ -67,9 +67,7 @@ void block_writer_release(struct block_writer *bw);
struct block_iter {
/* offset within the block of the next entry to read. */
uint32_t next_off;
const unsigned char *block;
size_t block_len;
uint32_t hash_size;
const struct reftable_block *block;
/* key for last entry we read. */
struct reftable_buf last_key;