From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Matheus Tavares <matheus.bernardino@usp.br>
Cc: git@vger.kernel.org, gitster@pobox.com, larsxschneider@gmail.com,
christian.couder@gmail.com
Subject: Re: [PATCH 1/2] t/t0021: convert the rot13-filter.pl script to C
Date: Sat, 23 Jul 2022 06:59:49 +0200 [thread overview]
Message-ID: <220723.86pmhwquie.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <99823077be77bc621cfa8ccf3303bd612da343ad.1658518769.git.matheus.bernardino@usp.br>
On Fri, Jul 22 2022, Matheus Tavares wrote:
Looking a bit closer...
> however, that we still use the script as a wrapper at
> this commit, in order to minimize the amount of changes it introduces
> and help reviewers. At the next commit we will properly remove the
> script and adjust the affected tests to use test-tool.
I'd prefer if we just squashed this, if you want to avoid some of the
diff verbosity you could leave the PERL prereq on all the
test_expect_success and remove it in a 2/2 (we just wouldn't run the
test until then).
But I think it's all boilerplate, so just doing it in one step would be
better, reasoning about the in-between steps is harder IMO (e.g. "exec"
escaping or whatever)>
> +static char *rot13(char *str)
> +{
> + char *c;
> + for (c = str; *c; c++) {
> + if (*c >= 'a' && *c <= 'z')
> + *c = 'a' + (*c - 'a' + 13) % 26;
> + else if (*c >= 'A' && *c <= 'Z')
> + *c = 'A' + (*c - 'A' + 13) % 26;
> + }
> + return str;
> +}
Looks fine, but we should probably put in our CodingGuidelines at some
point that we don't care about EBCDIC, as this isn't portable C (but
probably portable enough, as we can probably assume ASCII) :)
> +static struct string_list *packet_read_capabilities(void)
> +{
> + struct string_list *caps = xmalloc(sizeof(*caps));
malloc here...
> + string_list_init_dup(caps);
> + while (1) {
> + int size;
> + char *buf = packet_read_line(0, &size);
> + if (!buf)
> + break;
> + string_list_append_nodup(caps,
> + skip_key_dup(buf, size, "capability"));
> + }
> + return caps;
> +}
> +
> +/* Read remote capabilities and check them against capabilities we require */
> +static struct string_list *packet_read_and_check_capabilities(
> + struct string_list *required_caps)
> +{
> + struct string_list *remote_caps = packet_read_capabilities();
...and here...
> + struct string_list_item *item;
> + for_each_string_list_item(item, required_caps) {
> + if (!unsorted_string_list_has_string(remote_caps, item->string)) {
> + die("required '%s' capability not available from remote",
> + item->string);
> + }
> + }
> + return remote_caps;
...we'll return it...
> + remote_caps = packet_read_and_check_capabilities(&supported_caps);
> + packet_check_and_write_capabilities(remote_caps, &requested_caps);
> + fprintf(logfile, "init handshake complete\n");
> +
> + string_list_clear(&supported_caps, 0);
> + string_list_clear(remote_caps, 0);
..and here you're missing a free(), but I wonder why not just declare
this string_list in this function, and pass it down instead?
It's unfortunate that none of these tests seem to pass with
SANITIZE=leak already, but the new command seems not to leak from a
trivial glance except for in that one case.
Not knowing much about the filtering mechanism, I wonder if this code
here wouldn't be better as a built-in some day. I.e. isn't this all
shimmy we need to talk to some arbitrary conversion filter, except for
the rot13 part?
So if we just invoked a "tr" with run_command() to do the actual rot13
filtering we could do any sort of arbitrary replacement, and present a
variant of this this command as a "if you can't be bothered with
packet-line" in gitattributes(5)...
...but maybe that's hopeless for some reason I'm missing, in any case,
more #leftoverbits.
next prev parent reply other threads:[~2022-07-23 5:16 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-22 19:42 [PATCH 0/2] t0021: convert perl script to C test-tool helper Matheus Tavares
2022-07-22 19:42 ` [PATCH 1/2] t/t0021: convert the rot13-filter.pl script to C Matheus Tavares
2022-07-23 4:52 ` Ævar Arnfjörð Bjarmason
2022-07-23 4:59 ` Ævar Arnfjörð Bjarmason [this message]
2022-07-23 13:36 ` Matheus Tavares
2022-07-22 19:42 ` [PATCH 2/2] t/t0021: replace old rot13-filter.pl uses with new test-tool cmd Matheus Tavares
2022-07-24 15:09 ` [PATCH v2] t/t0021: convert the rot13-filter.pl script to C Matheus Tavares
2022-07-28 16:58 ` Johannes Schindelin
2022-07-28 17:54 ` Junio C Hamano
2022-07-28 19:50 ` Ævar Arnfjörð Bjarmason
2022-07-31 2:52 ` Matheus Tavares
2022-08-09 9:36 ` Johannes Schindelin
2022-07-31 18:19 ` [PATCH v3 0/3] t0021: convert perl script to C test-tool helper Matheus Tavares
2022-07-31 18:19 ` [PATCH v3 1/3] t0021: avoid grepping for a Perl-specific string at filter output Matheus Tavares
2022-08-01 20:41 ` Junio C Hamano
2022-07-31 18:19 ` [PATCH v3 2/3] t0021: implementation the rot13-filter.pl script in C Matheus Tavares
2022-08-01 11:33 ` Ævar Arnfjörð Bjarmason
2022-08-02 0:16 ` Matheus Tavares
2022-08-09 9:45 ` Johannes Schindelin
2022-08-01 11:39 ` Ævar Arnfjörð Bjarmason
2022-08-01 21:18 ` Junio C Hamano
2022-08-02 0:13 ` Matheus Tavares
2022-08-09 10:00 ` Johannes Schindelin
2022-08-10 18:37 ` Junio C Hamano
2022-08-10 19:58 ` Junio C Hamano
2022-08-09 10:37 ` Johannes Schindelin
2022-08-09 10:47 ` Johannes Schindelin
2022-07-31 18:19 ` [PATCH v3 3/3] tests: use the new C rot13-filter helper to avoid PERL prereq Matheus Tavares
2022-08-15 1:06 ` [PATCH v4 0/3] t0021: convert perl script to C test-tool helper Matheus Tavares
2022-08-15 1:06 ` [PATCH v4 1/3] t0021: avoid grepping for a Perl-specific string at filter output Matheus Tavares
2022-08-15 1:06 ` [PATCH v4 2/3] t0021: implementation the rot13-filter.pl script in C Matheus Tavares
2022-08-15 1:06 ` [PATCH v4 3/3] tests: use the new C rot13-filter helper to avoid PERL prereq Matheus Tavares
2022-08-15 13:01 ` [PATCH v4 0/3] t0021: convert perl script to C test-tool helper Johannes Schindelin
2022-08-19 22:17 ` 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=220723.86pmhwquie.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=larsxschneider@gmail.com \
--cc=matheus.bernardino@usp.br \
/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).