From: karthik nayak <karthik.188@gmail.com>
To: Patrick Steinhardt <ps@pks.im>, git@vger.kernel.org
Cc: Edward Thomson <ethomson@edwardthomson.com>
Subject: Re: [PATCH 02/10] reftable: stop using `strbuf_addf()`
Date: Fri, 11 Oct 2024 02:51:57 -0700 [thread overview]
Message-ID: <CAOLa=ZTHuWstTD56ZVTecW7ThHhpEqmrL28Emt5DtPL6pYhcpw@mail.gmail.com> (raw)
In-Reply-To: <abc28d7664f151e00568a6a3d18bf8a2de46470d.1728629612.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]
Patrick Steinhardt <ps@pks.im> writes:
[snip]
> diff --git a/t/unit-tests/t-reftable-readwrite.c b/t/unit-tests/t-reftable-readwrite.c
> index 27ce84445e8..5f59b0ad6ad 100644
> --- a/t/unit-tests/t-reftable-readwrite.c
> +++ b/t/unit-tests/t-reftable-readwrite.c
> @@ -753,12 +753,13 @@ static void t_write_multiple_indices(void)
> struct reftable_write_options opts = {
> .block_size = 100,
> };
> - struct strbuf writer_buf = STRBUF_INIT, buf = STRBUF_INIT;
> + struct strbuf writer_buf = STRBUF_INIT;
> struct reftable_block_source source = { 0 };
> struct reftable_iterator it = { 0 };
> const struct reftable_stats *stats;
> struct reftable_writer *writer;
> struct reftable_reader *reader;
> + char buf[128];
> int err, i;
>
> writer = t_reftable_strbuf_writer(&writer_buf, &opts);
> @@ -770,9 +771,8 @@ static void t_write_multiple_indices(void)
> .value.val1 = {i},
> };
>
> - strbuf_reset(&buf);
Here, it is okay to remove this, since we define our own buf array.
> - strbuf_addf(&buf, "refs/heads/%04d", i);
> - ref.refname = buf.buf,
> + snprintf(buf, sizeof(buf), "refs/heads/%04d", i);
> + ref.refname = buf;
>
> err = reftable_writer_add_ref(writer, &ref);
> check(!err);
> @@ -788,9 +788,8 @@ static void t_write_multiple_indices(void)
[snip]
> @@ -1077,8 +1078,10 @@ static void t_reftable_stack_auto_compaction_with_locked_tables(void)
> * size, we expect that auto-compaction will want to compact all of the
> * tables. Locking any of the tables will keep it from doing so.
> */
> - strbuf_reset(&buf);
However here it is different, since we still use the strbuf. I guess it
should be okay, since 'buf' is initialized using 'STRBUF_INIT' and that
still keeps the buf.len to 0.
> - strbuf_addf(&buf, "%s/%s.lock", dir, st->readers[2]->name);
> + strbuf_addstr(&buf, dir);
> + strbuf_addstr(&buf, "/");
> + strbuf_addstr(&buf, st->readers[2]->name);
> + strbuf_addstr(&buf, ".lock");
> write_file_buf(buf.buf, "", 0);
>
So when we do 'strbuf_addstr(&buf, ...)' it should allocate the required
memory. But the reset removal did catch my eye.
[snip]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]
next prev parent reply other threads:[~2024-10-11 9:51 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 6:54 [PATCH 00/10] reftable: stop using `struct strbuf` Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 01/10] reftable: stop using `strbuf_addbuf()` Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 02/10] reftable: stop using `strbuf_addf()` Patrick Steinhardt
2024-10-11 9:51 ` karthik nayak [this message]
2024-10-14 13:09 ` Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 03/10] reftable/basics: provide new `reftable_buf` interface Patrick Steinhardt
2024-10-11 10:03 ` karthik nayak
2024-10-14 13:09 ` Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 04/10] reftable: convert from `strbuf` to `reftable_buf` Patrick Steinhardt
2024-10-11 12:12 ` karthik nayak
2024-10-14 13:09 ` Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 05/10] reftable/blocksource: adapt interface name Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 06/10] t/unit-tests: check for `reftable_buf` allocation errors Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 07/10] reftable/stack: adapt `format_name()` to handle allocation failures Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 08/10] reftable/record: adapt `reftable_record_key()` " Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 09/10] reftable/stack: adapt `stack_filename()` " Patrick Steinhardt
2024-10-11 6:54 ` [PATCH 10/10] reftable: handle trivial `reftable_buf` errors Patrick Steinhardt
2024-10-11 12:18 ` [PATCH 00/10] reftable: stop using `struct strbuf` karthik nayak
2024-10-14 13:09 ` Patrick Steinhardt
2024-10-14 13:02 ` [PATCH v2 " Patrick Steinhardt
2024-10-14 13:02 ` [PATCH v2 01/10] reftable: stop using `strbuf_addbuf()` Patrick Steinhardt
2024-10-14 22:19 ` Taylor Blau
2024-10-14 13:02 ` [PATCH v2 02/10] reftable: stop using `strbuf_addf()` Patrick Steinhardt
2024-10-14 22:32 ` Taylor Blau
2024-10-15 4:37 ` Patrick Steinhardt
2024-10-15 19:26 ` Taylor Blau
2024-10-14 13:02 ` [PATCH v2 03/10] reftable/basics: provide new `reftable_buf` interface Patrick Steinhardt
2024-10-14 22:34 ` Taylor Blau
2024-10-15 4:38 ` Patrick Steinhardt
2024-10-15 5:10 ` Eric Sunshine
2024-10-15 19:27 ` Taylor Blau
2024-10-16 8:42 ` Patrick Steinhardt
2024-10-16 20:56 ` Taylor Blau
2024-10-17 4:54 ` Patrick Steinhardt
2024-10-17 20:59 ` Taylor Blau
2024-10-14 13:02 ` [PATCH v2 04/10] reftable: convert from `strbuf` to `reftable_buf` Patrick Steinhardt
2024-10-14 22:35 ` Taylor Blau
2024-10-14 13:02 ` [PATCH v2 05/10] reftable/blocksource: adapt interface name Patrick Steinhardt
2024-10-14 13:02 ` [PATCH v2 06/10] t/unit-tests: check for `reftable_buf` allocation errors Patrick Steinhardt
2024-10-14 13:02 ` [PATCH v2 07/10] reftable/stack: adapt `format_name()` to handle allocation failures Patrick Steinhardt
2024-10-14 22:41 ` Taylor Blau
2024-10-14 13:02 ` [PATCH v2 08/10] reftable/record: adapt `reftable_record_key()` " Patrick Steinhardt
2024-10-14 13:02 ` [PATCH v2 09/10] reftable/stack: adapt `stack_filename()` " Patrick Steinhardt
2024-10-14 13:02 ` [PATCH v2 10/10] reftable: handle trivial `reftable_buf` errors Patrick Steinhardt
2024-10-14 22:44 ` [PATCH v2 00/10] reftable: stop using `struct strbuf` Taylor Blau
2024-10-15 4:37 ` Patrick Steinhardt
2024-10-15 10:33 ` shejialuo
2024-10-15 10:44 ` Patrick Steinhardt
2024-10-15 11:23 ` shejialuo
2024-10-17 4:53 ` [PATCH v3 " Patrick Steinhardt
2024-10-17 4:53 ` [PATCH v3 01/10] reftable: stop using `strbuf_addbuf()` Patrick Steinhardt
2024-10-17 4:53 ` [PATCH v3 02/10] reftable: stop using `strbuf_addf()` Patrick Steinhardt
2024-10-17 4:53 ` [PATCH v3 03/10] reftable/basics: provide new `reftable_buf` interface Patrick Steinhardt
2024-10-17 4:53 ` [PATCH v3 04/10] reftable: convert from `strbuf` to `reftable_buf` Patrick Steinhardt
2024-10-17 4:53 ` [PATCH v3 05/10] reftable/blocksource: adapt interface name Patrick Steinhardt
2024-10-17 4:54 ` [PATCH v3 06/10] t/unit-tests: check for `reftable_buf` allocation errors Patrick Steinhardt
2024-10-17 4:54 ` [PATCH v3 07/10] reftable/stack: adapt `format_name()` to handle allocation failures Patrick Steinhardt
2024-10-17 4:54 ` [PATCH v3 08/10] reftable/record: adapt `reftable_record_key()` " Patrick Steinhardt
2024-10-17 4:54 ` [PATCH v3 09/10] reftable/stack: adapt `stack_filename()` " Patrick Steinhardt
2024-10-17 4:54 ` [PATCH v3 10/10] reftable: handle trivial `reftable_buf` errors Patrick Steinhardt
2024-10-17 21:00 ` [PATCH v3 00/10] reftable: stop using `struct strbuf` Taylor Blau
2024-10-18 7:46 ` karthik nayak
2024-10-18 21:41 ` Taylor Blau
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='CAOLa=ZTHuWstTD56ZVTecW7ThHhpEqmrL28Emt5DtPL6pYhcpw@mail.gmail.com' \
--to=karthik.188@gmail.com \
--cc=ethomson@edwardthomson.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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).