On Fri, 24 May 2024, Patrick Steinhardt <ps@xxxxxx> wrote:
> On Fri, May 24, 2024 at 05:29:45AM +0530, Ghanshyam Thakkar wrote:
> > t/helper/test-sha256 and t/t0015-hash test the hash implementation of
> > SHA-256 in Git with basic SHA-256 hash values. Port them to the new
> > unit testing framework for better debugging, simplicity and faster
> > runtime. The necessary building blocks are already implemented in
> > t-hash in the previous commit which ported test-sha1.
> >
> > The 'sha256' subcommand of test-tool is still not removed, because it
> > is used by pack_trailer() in lib-pack.sh, which is used in many tests
> > of the t53** series.
>
> Similar question here, are there replacements we can use for it? I also
> couldn't see it being used in any test other than t0015 when searing for
> "test-tool sha256". Maybe I'm looking for the wrong thing?
It is used indirectly and not explicitly like 'test-tool sha256'. e.g.
in t/lib-pack.sh when GIT_TEST_DEFUALT_HASH=sha256, ...
# Compute and append pack trailer to "$1"
pack_trailer () {
test-tool $(test_oid algo) -b <"$1" >trailer.tmp &&
cat trailer.tmp >>"$1" &&
rm -f trailer.tmp
}
...it will use 'test-tool sha256' on the first line of pack_trailer().
And the pack_trailer() is used in t7450, t5308, t5309, t5321.
And I will consult with Christian and Kaartic on the replacements but as
Christian and Junio said, doing it in another series would be a good
idea.
> [snip]
> > -test_done
> > diff --git a/t/unit-tests/t-hash.c b/t/unit-tests/t-hash.c
> > index 89dfea9cc1..0f86cd3730 100644
> > --- a/t/unit-tests/t-hash.c
> > +++ b/t/unit-tests/t-hash.c
> > @@ -32,11 +32,24 @@ static void check_hash_data(const void *data, size_t data_length,
> > TEST(check_hash_data(literal, (sizeof(literal) - 1), expected, GIT_HASH_SHA1), \
> > "SHA1 (%s) works", #literal)
> >
> > +
> > +/* Works with a NUL terminated string. Doesn't work if it should contain a NUL character. */
> > +#define TEST_SHA256_STR(data, expected) \
> > + TEST(check_hash_data(data, strlen(data), expected, GIT_HASH_SHA256), \
> > + "SHA256 (%s) works", #data)
> > +
> > +/* Only works with a literal string, useful when it contains a NUL character. */
> > +#define TEST_SHA256_LITERAL(literal, expected) \
> > + TEST(check_hash_data(literal, (sizeof(literal) - 1), expected, GIT_HASH_SHA256), \
> > + "SHA256 (%s) works", #literal)
> > +
>
> Same question here regarding the macros and whether we can merge them.
>
> Also, we do have the same test data for both hashes, and if we ever grow
> another hash it's likely that we'll also want to check for the same
> inputs there. Would it make sense to have a generic `TAST_HASHES()`
> macro where you give the input and then both the expected SHA1 and
> SHA256 to avoid some duplication?
Yeah, that can be done as the inputs are same for both hashes minus one
extra for sha256 (though I think it can be easily obtained). It looks
like a good idea to me for v4.
Thank you for the review!
