On Fri, Aug 16, 2024 at 10:55:32PM +0530, Chandra Pratap wrote:
> @@ -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@xxxxxx>
