git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Patrick Steinhardt <ps@pks.im>
Date
Oct 17, 2024, 04:53 UTC
Message-ID
<cover.1729140565.git.ps@pks.im>
In-Reply-To
<cover.1728629612.git.ps@pks.im>
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
-- 
2.47.0.72.gef8ce8f3d4.dirty
Previous: shejialuoNext: Patrick Steinhardt
Message 50 of 63 in “reftable: stop using `struct strbuf`”
  1. 00/10 reftable: stop using `struct strbuf`Patrick Steinhardt, Oct 11, 2024
  2. 01/10 reftable: stop using `strbuf_addbuf()`Patrick Steinhardt, Oct 11, 2024
  3. 02/10 reftable: stop using `strbuf_addf()`Patrick Steinhardt, Oct 11, 2024
  4. karthik nayakOct 11, 2024
  5. Patrick SteinhardtOct 14, 2024
  6. 03/10 reftable/basics: provide new `reftable_buf` interfacePatrick Steinhardt, Oct 11, 2024
  7. karthik nayakOct 11, 2024
  8. Patrick SteinhardtOct 14, 2024
  9. 04/10 reftable: convert from `strbuf` to `reftable_buf`Patrick Steinhardt, Oct 11, 2024
  10. karthik nayakOct 11, 2024
  11. Patrick SteinhardtOct 14, 2024
  12. 05/10 reftable/blocksource: adapt interface namePatrick Steinhardt, Oct 11, 2024
  13. 06/10 t/unit-tests: check for `reftable_buf` allocation errorsPatrick Steinhardt, Oct 11, 2024
  14. 07/10 reftable/stack: adapt `format_name()` to handle allocation failuresPatrick Steinhardt, Oct 11, 2024
  15. 08/10 reftable/record: adapt `reftable_record_key()` to handle allocation failuresPatrick Steinhardt, Oct 11, 2024
  16. 09/10 reftable/stack: adapt `stack_filename()` to handle allocation failuresPatrick Steinhardt, Oct 11, 2024
  17. 10/10 reftable: handle trivial `reftable_buf` errorsPatrick Steinhardt, Oct 11, 2024
  18. karthik nayakOct 11, 2024
  19. Patrick SteinhardtOct 14, 2024
  20. 00/10 reftable: stop using `struct strbuf`Patrick Steinhardt, Oct 14, 2024
  21. 01/10 reftable: stop using `strbuf_addbuf()`Patrick Steinhardt, Oct 14, 2024
  22. Taylor BlauOct 14, 2024
  23. 02/10 reftable: stop using `strbuf_addf()`Patrick Steinhardt, Oct 14, 2024
  24. Taylor BlauOct 14, 2024
  25. Patrick SteinhardtOct 15, 2024
  26. Taylor BlauOct 15, 2024
  27. 03/10 reftable/basics: provide new `reftable_buf` interfacePatrick Steinhardt, Oct 14, 2024
  28. Taylor BlauOct 14, 2024
  29. Patrick SteinhardtOct 15, 2024
  30. Eric SunshineOct 15, 2024
  31. Taylor BlauOct 15, 2024
  32. Patrick SteinhardtOct 16, 2024
  33. Taylor BlauOct 16, 2024
  34. Patrick SteinhardtOct 17, 2024
  35. Taylor BlauOct 17, 2024
  36. 04/10 reftable: convert from `strbuf` to `reftable_buf`Patrick Steinhardt, Oct 14, 2024
  37. Taylor BlauOct 14, 2024
  38. 05/10 reftable/blocksource: adapt interface namePatrick Steinhardt, Oct 14, 2024
  39. 06/10 t/unit-tests: check for `reftable_buf` allocation errorsPatrick Steinhardt, Oct 14, 2024
  40. 07/10 reftable/stack: adapt `format_name()` to handle allocation failuresPatrick Steinhardt, Oct 14, 2024
  41. Taylor BlauOct 14, 2024
  42. 08/10 reftable/record: adapt `reftable_record_key()` to handle allocation failuresPatrick Steinhardt, Oct 14, 2024
  43. 09/10 reftable/stack: adapt `stack_filename()` to handle allocation failuresPatrick Steinhardt, Oct 14, 2024
  44. 10/10 reftable: handle trivial `reftable_buf` errorsPatrick Steinhardt, Oct 14, 2024
  45. Taylor BlauOct 14, 2024
  46. Patrick SteinhardtOct 15, 2024
  47. shejialuoOct 15, 2024
  48. Patrick SteinhardtOct 15, 2024
  49. shejialuoOct 15, 2024
  50. 00/10 reftable: stop using `struct strbuf`Patrick Steinhardt, Oct 17, 2024
  51. 01/10 reftable: stop using `strbuf_addbuf()`Patrick Steinhardt, Oct 17, 2024
  52. 02/10 reftable: stop using `strbuf_addf()`Patrick Steinhardt, Oct 17, 2024
  53. 03/10 reftable/basics: provide new `reftable_buf` interfacePatrick Steinhardt, Oct 17, 2024
  54. 04/10 reftable: convert from `strbuf` to `reftable_buf`Patrick Steinhardt, Oct 17, 2024
  55. 05/10 reftable/blocksource: adapt interface namePatrick Steinhardt, Oct 17, 2024
  56. 06/10 t/unit-tests: check for `reftable_buf` allocation errorsPatrick Steinhardt, Oct 17, 2024
  57. 07/10 reftable/stack: adapt `format_name()` to handle allocation failuresPatrick Steinhardt, Oct 17, 2024
  58. 08/10 reftable/record: adapt `reftable_record_key()` to handle allocation failuresPatrick Steinhardt, Oct 17, 2024
  59. 09/10 reftable/stack: adapt `stack_filename()` to handle allocation failuresPatrick Steinhardt, Oct 17, 2024
  60. 10/10 reftable: handle trivial `reftable_buf` errorsPatrick Steinhardt, Oct 17, 2024
  61. Taylor BlauOct 17, 2024
  62. karthik nayakOct 18, 2024
  63. Taylor BlauOct 18, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.