Re: [PATCH 09/10] t-reftable-block: add tests for obj blocks

On Thu, 15 Aug 2024 at 15:11, Patrick Steinhardt [off-list ref] wrote:

On Wed, Aug 14, 2024 at 05:33:17PM +0530, Chandra Pratap wrote:

quoted

In the current testing setup, block operations are left unexercised
for obj blocks. Add a test that exercises these operations for obj
blocks.

Same remarks here as for the preceding commit.

quoted

@@ -186,9 +186,88 @@ static void t_log_block_read_write(void)
              reftable_record_release(&recs[i]);
 }

+static void t_obj_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 = 1024;
+     struct reftable_block block = { 0 };
+     struct block_writer bw = {
+             .last_key = STRBUF_INIT,
+     };
+     struct reftable_record rec = {
+             .type = BLOCK_TYPE_OBJ,
+     };
+     size_t i = 0;
+     int n;
+     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_OBJ, block.data, block_size,
+                       header_off, hash_size(GIT_SHA1_FORMAT_ID));
+
+     for (i = 0; i < N; i++) {
+             uint8_t *bytes = reftable_malloc(sizeof(uint8_t[5]));
+             memcpy(bytes, (uint8_t[]){i, i+1, i+2, i+3, i+5}, sizeof(uint8_t[5]));

From the top of my head I'm not sure whether we use inline-array
declarations like this anywhere. I'd rather just make it a separate
variable, which also allows us to get rid of the magic 5 via
`ARRAY_SIZE()`.

We _do_ use inline array declarations like this, here's an example from
t/unit-tests/t-prio-queue.c:
TEST(TEST_INPUT(((int []){ STACK, 1, 2, 3, 4, 5, 6, REVERSE, DUMP }),
          ((int []){ 1, 2, 3, 4, 5, 6 })), "prio-queue works when LIFO
stack is reversed");

I did implement bytes[] as a local variable array when I first worked
on this patch but that turned out to be tricky due to variable scoping
and pointer semantics, so I ultimately settled on this approach.