[v3,00/10] reftable: stop using `struct strbuf`

Message

Patrick Steinhardt Oct. 17, 2024, 4:53 a.m. UTC

Hi,

this is the third version of my patch series that removes use of `struct
strbuf` in the reftable library. The intent of this is to convert the
reftable library back into a standalone library that can be used in the
context of libgit2.

Changes compared to v2:

  - Provide more context around why we get rid of `stbuf_addf()`.

  - Fix a commit message type.

  - Provide better docs for `reftable_buf_add()`.

Thanks!

Patrick

Patrick Steinhardt (10):
  reftable: stop using `strbuf_addbuf()`
  reftable: stop using `strbuf_addf()`
  reftable/basics: provide new `reftable_buf` interface
  reftable: convert from `strbuf` to `reftable_buf`
  reftable/blocksource: adapt interface name
  t/unit-tests: check for `reftable_buf` allocation errors
  reftable/stack: adapt `format_name()` to handle allocation failures
  reftable/record: adapt `reftable_record_key()` to handle allocation
    failures
  reftable/stack: adapt `stack_filename()` to handle allocation failures
  reftable: handle trivial `reftable_buf` errors

 reftable/basics.c                   |  76 +++++++++-
 reftable/basics.h                   |  61 +++++++-
 reftable/block.c                    |  61 +++++---
 reftable/block.h                    |  14 +-
 reftable/blocksource.c              |  30 ++--
 reftable/blocksource.h              |   5 +-
 reftable/iter.c                     |   9 +-
 reftable/iter.h                     |   8 +-
 reftable/reader.c                   |  27 ++--
 reftable/record.c                   | 114 ++++++++------
 reftable/record.h                   |  21 +--
 reftable/stack.c                    | 221 ++++++++++++++++++----------
 reftable/system.h                   |   1 -
 reftable/writer.c                   | 102 ++++++++-----
 reftable/writer.h                   |   2 +-
 t/unit-tests/lib-reftable.c         |   4 +-
 t/unit-tests/lib-reftable.h         |   7 +-
 t/unit-tests/t-reftable-basics.c    |  16 +-
 t/unit-tests/t-reftable-block.c     |  53 +++----
 t/unit-tests/t-reftable-merged.c    |  32 ++--
 t/unit-tests/t-reftable-reader.c    |  12 +-
 t/unit-tests/t-reftable-readwrite.c | 134 +++++++++--------
 t/unit-tests/t-reftable-record.c    |  74 +++++-----
 t/unit-tests/t-reftable-stack.c     |  96 ++++++------
 24 files changed, 728 insertions(+), 452 deletions(-)

Range-diff against v2:
 1:  7408482c152 =  1:  7408482c152 reftable: stop using `strbuf_addbuf()`
 2:  6a7333b275e !  2:  634fd3c35f5 reftable: stop using `strbuf_addf()`
    @@ Commit message
         reftable: stop using `strbuf_addf()`
     
         We're about to introduce our own `reftable_buf` type to replace
    -    `strbuf`. Get rid of the seldomly-used `strbuf_addf()` function such
    -    that we have to reimplement one less function.
    +    `strbuf`. One function we'll have to convert is `strbuf_addf()`, which
    +    is used in a handful of places. This function uses `snprintf()`
    +    internally, which makes porting it a bit more involved:
    +
    +      - It is not available on all platforms.
    +
    +      - Some platforms like Windows have broken implementations.
    +
    +    So by using `snprintf()` we'd also push the burden on downstream users
    +    of the reftable library to make available a properly working version of
    +    it.
    +
    +    Most callsites of `strbuf_addf()` are trivial to convert to not using
    +    it. We do end up using `snprintf()` in our unit tests, but that isn't
    +    much of a problem for downstream users of the reftable library.
     
         While at it, remove a useless call to `strbuf_reset()` in
         `t_reftable_stack_auto_compaction_with_locked_tables()`. We don't write
 3:  0ddc8c0c896 !  3:  53c5f667f28 reftable/basics: provide new `reftable_buf` interface
    @@ Commit message
             to make things work, which is not all that sensible.
     
           - The `strbuf` interface does not use the pluggable allocators that
    -        can be set up via `refatble_set_alloc()`.
    +        can be set up via `reftable_set_alloc()`.
     
         So we have good reasons to use our own type, and the implementation is
         rather trivial. Implement our own type. Conversion of the reftable
 4:  e1ff1af1f30 !  4:  7c7ccc5d966 reftable: convert from `strbuf` to `reftable_buf`
    @@ reftable/basics.c: int names_equal(const char **a, const char **b)
      	for (; p < a->len && p < b->len; p++) {
     
      ## reftable/basics.h ##
    +@@ reftable/basics.h: int reftable_buf_setlen(struct reftable_buf *buf, size_t len);
    + int reftable_buf_cmp(const struct reftable_buf *a, const struct reftable_buf *b);
    + 
    + /*
    +- * Add the given bytes to the buffer. Returns 0 on success,
    ++ * Append `len` bytes from `data` to the buffer. This function works with
    ++ * arbitrary byte sequences, including ones that contain embedded NUL
    ++ * characters. As such, we use `void *` as input type. Returns 0 on success,
    +  * REFTABLE_OUT_OF_MEMORY_ERROR on allocation failure.
    +  */
    + int reftable_buf_add(struct reftable_buf *buf, const void *data, size_t len);
     @@ reftable/basics.h: char *reftable_strdup(const char *str);
      #endif
      
 5:  fe8c9ace463 =  5:  f9632860933 reftable/blocksource: adapt interface name
 6:  8c98745233a =  6:  d850a2fe7d0 t/unit-tests: check for `reftable_buf` allocation errors
 7:  1f08163009b =  7:  8f8e2ca3962 reftable/stack: adapt `format_name()` to handle allocation failures
 8:  5798d76d7a4 =  8:  268e4cd6fc6 reftable/record: adapt `reftable_record_key()` to handle allocation failures
 9:  a9582d51dd1 =  9:  245a428842a reftable/stack: adapt `stack_filename()` to handle allocation failures
10:  90819c90f38 = 10:  4b51ea4b628 reftable: handle trivial `reftable_buf` errors

Comments

Taylor Blau Oct. 17, 2024, 9 p.m. UTC | #1

On Thu, Oct 17, 2024 at 06:53:42AM +0200, Patrick Steinhardt wrote:
> Range-diff against v2:

The range-diff looks like we're getting close here, or are already
there. Do others agree that this is ready to start merging down?

Thanks,
Taylor

Karthik Nayak Oct. 18, 2024, 7:46 a.m. UTC | #2

Taylor Blau <[e-mail]> writes:

> On Thu, Oct 17, 2024 at 06:53:42AM +0200, Patrick Steinhardt wrote:
>> Range-diff against v2:
>
> The range-diff looks like we're getting close here, or are already
> there. Do others agree that this is ready to start merging down?
>
> Thanks,
> Taylor

I had already reviewed version 1, having a look at the range-diff now,
seems like it is ready to be merged!

Thanks,
Karthik