git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
Cc: ach.lumap@gmail.com, chriscool@tuxfamily.org,
	christian.couder@gmail.com, git@vger.kernel.org,
	gitster@pobox.com, kaartic.sivaraam@gmail.com
Subject: Re: [PATCH v3 2/3] t/: port helper/test-sha1.c to unit-tests/t-hash.c
Date: Fri, 24 May 2024 15:30:26 +0200	[thread overview]
Message-ID: <ZlCWcpcUkgUMWJYz@tanuki> (raw)
In-Reply-To: <20240523235945.26833-3-shyamthakkar001@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

On Fri, May 24, 2024 at 05:29:44AM +0530, Ghanshyam Thakkar wrote:
> t/helper/test-sha1 and t/t0015-hash.sh test the hash implementation of
> SHA-1 in Git with basic SHA-1 hash values. Migrate them to the new unit
> testing framework for better debugging and runtime performance.
> 
> The sha1 subcommand from test-tool is still not removed because it is
> relied upon by t0013-sha1dc (which requires 'test-tool sha1' dying
> when it is used on a file created to contain the known sha1 attack)
> and pack_trailer():lib-pack.sh.

Can we refactor this test to stop doing that? E.g., would it work if we
used git-hash-object(1) to check that SHA1DC does its thing? Then we
could get rid of the helper altogether, as far as I understand.

> diff --git a/t/unit-tests/t-hash.c b/t/unit-tests/t-hash.c
> new file mode 100644
> index 0000000000..89dfea9cc1
> --- /dev/null
> +++ b/t/unit-tests/t-hash.c
> @@ -0,0 +1,54 @@
> +#include "test-lib.h"
> +#include "hash-ll.h"
> +#include "hex.h"
> +#include "strbuf.h"
> +
> +static void check_hash_data(const void *data, size_t data_length,
> +			    const char *expected, int algo)
> +{
> +	git_hash_ctx ctx;
> +	unsigned char hash[GIT_MAX_HEXSZ];
> +	const struct git_hash_algo *algop = &hash_algos[algo];
> +
> +	if (!check(!!data)) {

Is this double negation needed? Can't we just `if (!check(data))`?

> +		test_msg("Error: No data provided when expecting: %s", expected);

This error message is a bit atypical compared to the other callers of
this function. We could say something like "BUG: test has no data",
which would match something we have in "t/unit-tests/test-lib.c".

> +		return;
> +	}
> +
> +	algop->init_fn(&ctx);
> +	algop->update_fn(&ctx, data, data_length);
> +	algop->final_fn(hash, &ctx);
> +
> +	check_str(hash_to_hex_algop(hash, algop), expected);
> +}
> +
> +/* Works with a NUL terminated string. Doesn't work if it should contain a NUL character. */
> +#define TEST_SHA1_STR(data, expected) \
> +	TEST(check_hash_data(data, strlen(data), expected, GIT_HASH_SHA1), \
> +	     "SHA1 (%s) works", #data)
> +
> +/* Only works with a literal string, useful when it contains a NUL character. */
> +#define TEST_SHA1_LITERAL(literal, expected) \
> +	TEST(check_hash_data(literal, (sizeof(literal) - 1), expected, GIT_HASH_SHA1), \
> +	     "SHA1 (%s) works", #literal)
> 

This macro also works for `TEST_SHA1_STR()`, right? Is there a
partiuclar reason why we don't unify them?

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-05-24 13:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26 14:33 [Outreachy][PATCH 1/2] strbuf: introduce strbuf_addstrings() to repeatedly add a string Achu Luma
2024-02-26 14:33 ` [Outreachy][PATCH 2/2] Port helper/test-sha256.c and helper/test-sha1.c to unit-tests/t-hash.c Achu Luma
2024-02-26 16:39 ` [Outreachy][PATCH 1/2] strbuf: introduce strbuf_addstrings() to repeatedly add a string Junio C Hamano
2024-02-26 17:15   ` Christian Couder
2024-02-26 18:10     ` Junio C Hamano
2024-02-27 10:07       ` Christian Couder
2024-02-29  5:40 ` [Outreachy][PATCH v2 " Achu Luma
2024-02-29  5:40   ` [Outreachy][PATCH v2 2/2] Port helper/test-sha256.c and helper/test-sha1.c to unit-tests/t-hash.c Achu Luma
2024-03-06 14:25     ` Christian Couder
2024-03-26 11:39     ` Patrick Steinhardt
2024-03-26 11:51       ` Christian Couder
2024-05-16 19:30     ` Ghanshyam Thakkar
2024-05-23 23:59   ` [PATCH v3 0/3] Port t0015-hash to the unit testing framework Ghanshyam Thakkar
2024-05-23 23:59     ` [PATCH v3 1/3] strbuf: introduce strbuf_addstrings() to repeatedly add a string Ghanshyam Thakkar
2024-05-23 23:59     ` [PATCH v3 2/3] t/: port helper/test-sha1.c to unit-tests/t-hash.c Ghanshyam Thakkar
2024-05-24 13:30       ` Patrick Steinhardt [this message]
2024-05-24 14:08         ` Christian Couder
2024-05-24 15:49           ` Junio C Hamano
2024-06-15 20:14             ` Ghanshyam Thakkar
2024-06-16  4:52               ` Jeff King
2024-06-17 17:44                 ` Junio C Hamano
2024-06-21 18:37                 ` Ghanshyam Thakkar
2024-05-23 23:59     ` [PATCH v3 3/3] t/: port helper/test-sha256.c " Ghanshyam Thakkar
2024-05-24 13:30       ` Patrick Steinhardt
2024-05-25  1:15         ` Ghanshyam Thakkar
2024-05-26  8:43     ` [PATCH v4 0/2] t/: port helper/test-{sha1, sha256} to unit-tests/t-hash Ghanshyam Thakkar
2024-05-26  8:43       ` [PATCH v4 1/2] strbuf: introduce strbuf_addstrings() to repeatedly add a string Ghanshyam Thakkar
2024-05-26  8:43       ` [PATCH v4 2/2] t/: migrate helper/test-{sha1, sha256} to unit-tests/t-hash Ghanshyam Thakkar
2024-05-29  6:26         ` Patrick Steinhardt
2024-05-29 14:54           ` Junio C Hamano
2024-05-29  8:00       ` [GSoC][PATCH v5 0/2] " Ghanshyam Thakkar
2024-05-29  8:00         ` [PATCH v5 1/2] strbuf: introduce strbuf_addstrings() to repeatedly add a string Ghanshyam Thakkar
2024-05-29  8:00         ` [PATCH v5 2/2] t/: migrate helper/test-{sha1, sha256} to unit-tests/t-hash Ghanshyam Thakkar
2024-05-29  9:19         ` [GSoC][PATCH v5 0/2] " Patrick Steinhardt
2024-05-29 16:09           ` 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=ZlCWcpcUkgUMWJYz@tanuki \
    --to=ps@pks.im \
    --cc=ach.lumap@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kaartic.sivaraam@gmail.com \
    --cc=shyamthakkar001@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).