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

[PATCH 2/4] strbuf.h: drop asciidoc list formatting from API docs

From
Jeff King <peff@peff.net>
Date
Dec 12, 2014, 21:28 UTC
Message-ID
<20141212212820.GB27451@peff.net>
In-Reply-To
<20141212212726.GA26284@peff.net>

Using a hanging indent is much more readable. This means we won't format as asciidoc anymore, but since we don't have a working system for extracting these comments anyway, it's probably more important to just make the source readable.

Signed-off-by: Jeff King <peff@peff.net>
---
 strbuf.h | 74 ++++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/strbuf.h b/strbuf.h
index 0a83f9a..8f63b38 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -13,44 +13,44 @@
  *
  * strbufs have some invariants that are very important to keep in mind:
  *
- * . The `buf` member is never NULL, so it can be used in any usual C
- * string operations safely. strbuf's _have_ to be initialized either by
- * `strbuf_init()` or by `= STRBUF_INIT` before the invariants, though.
- * +
- * Do *not* assume anything on what `buf` really is (e.g. if it is
- * allocated memory or not), use `strbuf_detach()` to unwrap a memory
- * buffer from its strbuf shell in a safe way. That is the sole supported
- * way. This will give you a malloced buffer that you can later `free()`.
- * +
- * However, it is totally safe to modify anything in the string pointed by
- * the `buf` member, between the indices `0` and `len-1` (inclusive).
+ *  - The `buf` member is never NULL, so it can be used in any usual C
+ *    string operations safely. strbuf's _have_ to be initialized either by
+ *    `strbuf_init()` or by `= STRBUF_INIT` before the invariants, though.
  *
- * . The `buf` member is a byte array that has at least `len + 1` bytes
- *   allocated. The extra byte is used to store a `'\0'`, allowing the
- *   `buf` member to be a valid C-string. Every strbuf function ensure this
- *   invariant is preserved.
- * +
- * NOTE: It is OK to "play" with the buffer directly if you work it this
- *       way:
- * +
- * ----
- * strbuf_grow(sb, SOME_SIZE); <1>
- * strbuf_setlen(sb, sb->len + SOME_OTHER_SIZE);
- * ----
- * <1> Here, the memory array starting at `sb->buf`, and of length
- * `strbuf_avail(sb)` is all yours, and you can be sure that
- * `strbuf_avail(sb)` is at least `SOME_SIZE`.
- * +
- * NOTE: `SOME_OTHER_SIZE` must be smaller or equal to `strbuf_avail(sb)`.
- * +
- * Doing so is safe, though if it has to be done in many places, adding the
- * missing API to the strbuf module is the way to go.
- * +
- * WARNING: Do _not_ assume that the area that is yours is of size `alloc
- * - 1` even if it's true in the current implementation. Alloc is somehow a
- * "private" member that should not be messed with. Use `strbuf_avail()`
- * instead.
- */
+ *    Do *not* assume anything on what `buf` really is (e.g. if it is
+ *    allocated memory or not), use `strbuf_detach()` to unwrap a memory
+ *    buffer from its strbuf shell in a safe way. That is the sole supported
+ *    way. This will give you a malloced buffer that you can later `free()`.
+ *
+ *    However, it is totally safe to modify anything in the string pointed by
+ *    the `buf` member, between the indices `0` and `len-1` (inclusive).
+ *
+ *  - The `buf` member is a byte array that has at least `len + 1` bytes
+ *    allocated. The extra byte is used to store a `'\0'`, allowing the
+ *    `buf` member to be a valid C-string. Every strbuf function ensure this
+ *    invariant is preserved.
+ *
+ *    NOTE: It is OK to "play" with the buffer directly if you work it this
+ *    way:
+ *
+ *    ----
+ *    strbuf_grow(sb, SOME_SIZE); <1>
+ *    strbuf_setlen(sb, sb->len + SOME_OTHER_SIZE);
+ *    ----
+ *    <1> Here, the memory array starting at `sb->buf`, and of length
+ *    `strbuf_avail(sb)` is all yours, and you can be sure that
+ *    `strbuf_avail(sb)` is at least `SOME_SIZE`.
+ *
+ *    NOTE: `SOME_OTHER_SIZE` must be smaller or equal to `strbuf_avail(sb)`.
+ *
+ *    Doing so is safe, though if it has to be done in many places, adding the
+ *    missing API to the strbuf module is the way to go.
+ *
+ *    WARNING: Do _not_ assume that the area that is yours is of size `alloc
+ *    - 1` even if it's true in the current implementation. Alloc is somehow a
+ *    "private" member that should not be messed with. Use `strbuf_avail()`
+ *    instead.
+*/
 
 /*
  * Data Structures
-- 
2.2.0.454.g7eca6b7
Previous: Jonathan NiederNext: Junio C Hamano
Message 31 of 49 in “document string_list_clear”
  1. document string_list_clearStefan Beller, Dec 6, 2014
  2. Jonathan NiederDec 6, 2014
  3. Jeff KingDec 6, 2014
  4. Jeff KingDec 6, 2014
  5. Junio C HamanoDec 9, 2014
  6. Jeff KingDec 9, 2014
  7. Jonathan NiederDec 9, 2014
  8. Junio C HamanoDec 9, 2014
  9. Stefan BellerDec 9, 2014
  10. Jonathan NiederDec 9, 2014
  11. Jeff KingDec 9, 2014
  12. Stefan BellerDec 9, 2014
  13. Jeff KingDec 9, 2014
  14. Jonathan NiederDec 9, 2014
  15. Junio C HamanoDec 9, 2014
  16. Jeff KingDec 10, 2014
  17. Jeff KingDec 10, 2014
  18. Jonathan NiederDec 10, 2014
  19. Jeff KingDec 12, 2014
  20. Jonathan NiederDec 12, 2014
  21. Junio C HamanoDec 12, 2014
  22. Stefan BellerDec 12, 2014
  23. Jeff KingDec 12, 2014
  24. Jeff KingDec 12, 2014
  25. Jonathan NiederDec 12, 2014
  26. Jeff KingDec 12, 2014
  27. 1/4 strbuf: migrate api-strbuf.txt documentation to strbuf.hJeff King, Dec 12, 2014
  28. Jeff KingDec 12, 2014
  29. Junio C HamanoDec 12, 2014
  30. Jonathan NiederDec 12, 2014
  31. 2/4 strbuf.h: drop asciidoc list formatting from API docsJeff King, Dec 12, 2014
  32. Junio C HamanoDec 12, 2014
  33. Jonathan NiederDec 12, 2014
  34. 3/4 strbuf.h: format asciidoc code blocks as 4-space indentJeff King, Dec 12, 2014
  35. Jonathan NiederDec 12, 2014
  36. Michael HaggertyDec 14, 2014
  37. 4/4 strbuf.h: reorganize api function grouping headersJeff King, Dec 12, 2014
  38. Jonathan NiederDec 12, 2014
  39. Stefan BellerDec 12, 2014
  40. Michael HaggertyDec 10, 2014
  41. Jonathan NiederDec 10, 2014
  42. Junio C HamanoDec 10, 2014
  43. Jonathan NiederDec 10, 2014
  44. Junio C HamanoDec 10, 2014
  45. Jonathan NiederDec 10, 2014
  46. Jonathan NiederDec 9, 2014
  47. Stefan BellerDec 9, 2014
  48. Jonathan NiederDec 9, 2014
  49. Jonathan NiederDec 9, 2014

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.