Re: [PATCH v2 09/11] t-reftable-block: add tests for log blocks

From: Patrick Steinhardt <ps@pks.im>
Date: Aug 21, 2024, 07:28 UTC
Message-ID: <ZsWXF_zJTIsp8XOE@tanuki>
In-Reply-To: <20240816175414.5169-10-chandrapratap3519@gmail.com>

On Fri, Aug 16, 2024 at 10:55:32PM +0530, Chandra Pratap wrote:

Show 28 quoted lines

> @@ -103,9 +103,97 @@ static void t_block_read_write(void)
>  		reftable_record_release(&recs[i]);
>  }
>  
> +static void t_log_block_read_write(void)
> +{
> +	const int header_off = 21;
> +	struct reftable_record recs[30];
> +	const size_t N = ARRAY_SIZE(recs);
> +	const size_t block_size = 2048;
> +	struct reftable_block block = { 0 };
> +	struct block_writer bw = {
> +		.last_key = STRBUF_INIT,
> +	};
> +	struct reftable_record rec = {
> +		.type = BLOCK_TYPE_LOG,
> +	};
> +	size_t i = 0;
> +	int ret;
> +	struct block_reader br = { 0 };
> +	struct block_iter it = BLOCK_ITER_INIT;
> +	struct strbuf want = STRBUF_INIT;
> +
> +	REFTABLE_CALLOC_ARRAY(block.data, block_size);
> +	block.len = block_size;
> +	block.source = malloc_block_source();
> +	block_writer_init(&bw, BLOCK_TYPE_LOG, block.data, block_size,
> +			  header_off, hash_size(GIT_SHA1_FORMAT_ID));

Nit: instead of a `malloc_block_source()`, you may use
`block_source_from_strbuf()`. The former will go away with the patch
series at [1].

I'm also happy to rebase my patch series once yours lands and do this myself. Guess yours will land faster anyway, and there are conflicts regardless of whether you do or don't update the test here. The same applies to the subsequent patches which use a `malloc_block_source()`.

So this isn't really worth a reroll by itself, and other than that this patch looks good to me.

Patrick

[1]: <cover.1724080006.git.ps@pks.im>