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

[PATCH 1/4] strbuf: fix doc for `strbuf_attach()`

From
MÅMartin Ågren <martin.agren@gmail.com>
Date
Apr 19, 2020, 12:32 UTC
Message-ID
<54e10bb06a39d23591ea4d02665083d705682468.1587297254.git.martin.agren@gmail.com>
In-Reply-To
<cover.1587297254.git.martin.agren@gmail.com>

Commit 917c9a7133 ("New strbuf APIs: splice and attach.", 2007-09-15) added `strbuf_attach()`. In the commit message, it is explicitly discussed how using `mem == len` is ok, although possibly costly. When this function was documented in dd613e6b87 ("Strbuf documentation: document most functions", 2008-06-04), this distinction was missed and the documentation simply forbids this case.

The function handles reallocation and truncation, yet the docs say that the "amount [of allocated memory] must be larger than the string length, because the string you pass is supposed to be a NUL-terminated string".

Several callers pass in `mem == len` meaning they are compatible with the implementation and the original commit message, but not with the documented behavior. In fact, compared to the documentation, they look outright dangerous.

Later commits will convert most of those call sites to use new, simpler interfaces, but in at least one instance we really do want to use this possibility of passing the same value twice: In rerere.c, it is not safe to pass in "len, len + 1". Doing so makes `strbuf_attach()` write a trailing NUL at `result.ptr[len]` and running our test suite with AddressSanitizer will spot an out-of-bounds write due to this.

That is, rerere.c really has use for the flexibility that `mem == len` gives us. Let's update the documentation to clarify that this is ok.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
 strbuf.h | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/strbuf.h b/strbuf.h
index ce8e49c0b2..2a462f70cc 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -112,10 +112,12 @@ char *strbuf_detach(struct strbuf *sb, size_t *sz);
 /**
  * Attach a string to a buffer. You should specify the string to attach,
  * the current length of the string and the amount of allocated memory.
- * The amount must be larger than the string length, because the string you
- * pass is supposed to be a NUL-terminated string.  This string _must_ be
- * malloc()ed, and after attaching, the pointer cannot be relied upon
- * anymore, and neither be free()d directly.
+ * The amount must be at least as large as the string length. If the two
+ * lengths are equal, reallocation will be handled as appropriate and in
+ * any case, the string will be NUL-truncated as implied by `len`.
+ *
+ * This string _must_ be malloc()ed, and after attaching, the pointer
+ * cannot be relied upon anymore, and neither be free()d directly.
  */
 void strbuf_attach(struct strbuf *sb, void *str, size_t len, size_t mem);
 
-- 
2.26.1
Previous: Martin ÅgrenNext: Junio C Hamano
Message 12 of 39 in “mailinfo.c::convert_to_utf8: reuse strlen info”
  1. mailinfo.c::convert_to_utf8: reuse strlen infoĐoàn Trần Công Danh, Apr 18, 2020
  2. Martin ÅgrenApr 18, 2020
  3. 0/6 strbuf: simplify `strbuf_attach()` usageMartin Ågren, Apr 18, 2020
  4. 1/6 am: use `strbuf_attach()` correctlyMartin Ågren, Apr 18, 2020
  5. 2/6 strbuf_attach: correctly pass in `strlen() + 1` for `alloc`Martin Ågren, Apr 18, 2020
  6. 3/6 strbuf: use `strbuf_attach()` correctlyMartin Ågren, Apr 18, 2020
  7. 4/6 fast-import: avoid awkward use of `strbuf_attach()`Martin Ågren, Apr 18, 2020
  8. 5/6 rerere: avoid awkward use of `strbuf_attach()`Martin Ågren, Apr 18, 2020
  9. 6/6 strbuf: simplify `strbuf_attach()` usageMartin Ågren, Apr 18, 2020
  10. Martin ÅgrenApr 19, 2020
  11. 0/4 strbuf: fix doc for `strbuf_attach()` and avoid itMartin Ågren, Apr 19, 2020
  12. 1/4 strbuf: fix doc for `strbuf_attach()`Martin Ågren, Apr 19, 2020
  13. Junio C HamanoApr 20, 2020
  14. Martin ÅgrenApr 21, 2020
  15. 2/4 strbuf: introduce `strbuf_attachstr_len()`Martin Ågren, Apr 19, 2020
  16. 3/4 strbuf: introduce `strbuf_attachstr()`Martin Ågren, Apr 19, 2020
  17. Junio C HamanoApr 20, 2020
  18. Martin ÅgrenApr 21, 2020
  19. 4/4 strbuf_attach: prefer `strbuf_attachstr_len()`Martin Ågren, Apr 19, 2020
  20. Junio C HamanoApr 18, 2020
  21. Danh DoanApr 19, 2020
  22. Martin ÅgrenApr 19, 2020
  23. Junio C HamanoApr 19, 2020
  24. 0/3 mailinfo: disallow and complains about NUL characterĐoàn Trần Công Danh, Apr 19, 2020
  25. 1/3 t4254: merge 2 steps of a single testĐoàn Trần Công Danh, Apr 19, 2020
  26. Martin ÅgrenApr 19, 2020
  27. Danh DoanApr 19, 2020
  28. 3/3 mailinfo: disallow NUL character in mail's headerĐoàn Trần Công Danh, Apr 19, 2020
  29. Martin ÅgrenApr 19, 2020
  30. Danh DoanApr 19, 2020
  31. 2/3 mailinfo.c::convert_to_utf8: reuse strlen infoĐoàn Trần Công Danh, Apr 19, 2020
  32. Martin ÅgrenApr 19, 2020
  33. Danh DoanApr 19, 2020
  34. Junio C HamanoApr 20, 2020
  35. Danh DoanApr 20, 2020
  36. 0/3 Disallow NUL character in mailinfoĐoàn Trần Công Danh, Apr 20, 2020
  37. 1/3 t4254: merge 2 steps of a single testĐoàn Trần Công Danh, Apr 20, 2020
  38. 2/3 mailinfo.c: avoid strlen on strings that can contains NULĐoàn Trần Công Danh, Apr 20, 2020
  39. 3/3 mailinfo: disallow NUL character in mail's headerĐoàn Trần Công Danh, Apr 20, 2020

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.