Re: [PATCH 04/10] t-reftable-block: use reftable_record_key() instead of strbuf_addstr()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 14, 2024 at 05:33:12PM +0530, Chandra Pratap wrote:
> In the current testing setup, the record key required for many block
> iterator functions is manually stored in a strbuf struct and then
> passed to these functions. This is not ideal when there exists a
> dedicated function to encode a record's key into a strbuf, namely
> reftable_record_key(). Use this function instead of manual encoding.
> 
> Mentored-by: Patrick Steinhardt <ps@xxxxxx>
> Mentored-by: Christian Couder <chriscool@xxxxxxxxxxxxx>
> Signed-off-by: Chandra Pratap <chandrapratap3519@xxxxxxxxx>
> ---
>  t/unit-tests/t-reftable-block.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/t/unit-tests/t-reftable-block.c b/t/unit-tests/t-reftable-block.c
> index baeb9c8b07..0d73fb98d6 100644
> --- a/t/unit-tests/t-reftable-block.c
> +++ b/t/unit-tests/t-reftable-block.c
> @@ -81,8 +81,7 @@ static void t_block_read_write(void)
>  
>  	for (i = 0; i < N; i++) {
>  		struct block_iter it = BLOCK_ITER_INIT;
> -		strbuf_reset(&want);
> -		strbuf_addstr(&want, recs[i].u.ref.refname);
> +		reftable_record_key(&recs[i], &want);
>  
>  		n = block_iter_seek_key(&it, &br, &want);
>  		check_int(n, ==, 0);

Yup, for ref records this is equivalent indeed, as their key only
consists of of the refname. It would be different for log records, which
also include the log index.

Patrick




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux