All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ghanshyam Thakkar" <shyamthakkar001@gmail.com>
To: "Christian Couder" <christian.couder@gmail.com>
Cc: <git@vger.kernel.org>,
	"Christian Couder" <chriscool@tuxfamily.org>,
	"Kaartic Sivaraam" <kaartic.sivaraam@gmail.com>,
	"Phillip Wood" <phillip.wood123@gmail.com>
Subject: Re: [GSoC][PATCH v2] t: port helper/test-oid-array.c to unit-tests/t-oid-array.c
Date: Sat, 24 Aug 2024 22:30:25 +0530	[thread overview]
Message-ID: <D3OAWJKG9PX9.6MOABOQ77MOB@gmail.com> (raw)
In-Reply-To: <CAP8UFD3E2idN6mUYzEyh11Fzmj07q+BQuyVCtUkPP=cuxsUODw@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> wrote:
> On Sat, Aug 3, 2024 at 3:22 PM Ghanshyam Thakkar
> <shyamthakkar001@gmail.com> wrote:
> > Migrate them to the unit testing framework for better runtime
> > performance and efficiency. Also 'the_hash_algo' is used internally in
>
> It doesn't seem to me that a variable called 'the_hash_algo' is used
> internally in oid_array_lookup() anymore.

It is. oid_array_lookup() uses oid_pos():hash-lookup.c, which uses
'the_hash_algo'.

> > +static void t_enumeration(const char **input_args, size_t input_sz,
> > +                         const char **result, size_t result_sz)
> > +{
> > +       struct oid_array input = OID_ARRAY_INIT, expect = OID_ARRAY_INIT,
> > +                        actual = OID_ARRAY_INIT;
> > +       size_t i;
> > +
> > +       if (fill_array(&input, input_args, input_sz))
> > +               return;
> > +       if (fill_array(&expect, result, result_sz))
> > +               return;
>
> It would have been nice if the arguments were called 'expect_args' and
> 'expect_sz' in the same way as for 'input'. Is there a reason why we
> couldn't just use 'expect' (or maybe 'expected') everywhere instead of
> 'result'?

I have changed them to 'expect' in v3.

> Also after the above 'input.nr' is equal to 'input_sz' and 'expect.nr'
> is equal to 'result_sz' otherwise we would have already returned fron
> the current function.
>
> > +       oid_array_for_each_unique(&input, add_to_oid_array, &actual);
> > +       check_uint(actual.nr, ==, expect.nr);
>
> I think it might be better to return if this check fails. Otherwise it
> means that we likely messed something up in the 'input_args' or
> 'result' arguments we passed to the function, and then...
>
> > +       for (i = 0; i < test_min(actual.nr, expect.nr); i++) {
> > +               if (!check(oideq(&actual.oid[i], &expect.oid[i])))
>
> ...we might not compare here the input oid with the corresponding
> result oid we intended to compare it to. This might result in a lot of
> not very relevant output.
>
> Returning if check_uint(actual.nr, ==, expect.nr) fails would avoid
> such output and also enable us to just use 'actual.nr' instead of
> 'test_min(actual.nr, expect.nr)' in the 'for' loop above.

Changed this in v3.

>
> > +                       test_msg("expected: %s\n       got: %s\n     index: %" PRIuMAX,
> > +                                oid_to_hex(&expect.oid[i]), oid_to_hex(&actual.oid[i]),
> > +                                (uintmax_t)i);
> > +       }
> > +       check_uint(i, ==, result_sz);
>
> As we saw above that 'expect.nr' is equal to 'result_sz', this check
> can fail only if 'actual.nr' is different from 'expect.nr' which we
> already checked above. So I think this check is redundant and we might
> want to get rid of it.

Removed in v3.

>
> In fill_array() above, we use check_int() to check the result of
> get_oid_arbitrary_hex() like this:
>
> if (!check_int(get_oid_arbitrary_hex(hexes[i], &oid), ==, 0))
>
> It doesn't look consistent to not use check_int() to check the result
> of get_oid_arbitrary_hex() here. Or is there a specific reason to do
> it in one place but not in another?

Not in particular. Added check_int() in v3.

Thanks for the review.

  reply	other threads:[~2024-08-24 17:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-03  3:46 [GSoC][PATCH] t: port helper/test-oid-array.c to unit-tests/t-oid-array.c Ghanshyam Thakkar
2024-07-04 16:33 ` Phillip Wood
2024-08-03 13:31   ` Ghanshyam Thakkar
2024-08-03 13:21 ` [GSoC][PATCH v2] " Ghanshyam Thakkar
2024-08-19 16:55   ` Christian Couder
2024-08-24 17:00     ` Ghanshyam Thakkar [this message]
2024-08-24 17:02   ` [GSoC][PATCH v3] " Ghanshyam Thakkar
2024-08-25  6:38     ` Christian Couder
2024-08-25 10:45       ` Ghanshyam Thakkar
2024-09-01 21:26     ` [PATCH v4] " Ghanshyam Thakkar
2024-09-04  7:42       ` Christian Couder
2024-09-04 15:01         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D3OAWJKG9PX9.6MOABOQ77MOB@gmail.com \
    --to=shyamthakkar001@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kaartic.sivaraam@gmail.com \
    --cc=phillip.wood123@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.