From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
Jonathan Nieder <jrnieder@gmail.com>,
Stefan Beller <sbeller@google.com>,
Junio C Hamano <gitster@pobox.com>
Subject: [PATCH 3/7] strbuf.h: drop asciidoc list formatting from API docs
Date: Fri, 16 Jan 2015 04:05:10 -0500 [thread overview]
Message-ID: <20150116090510.GC31113@peff.net> (raw)
In-Reply-To: <20150116090225.GA30797@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 fd57e45..ab5ff27 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.1.425.g441bb3c
next prev parent reply other threads:[~2015-01-16 9:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 9:02 [PATCH 0/7] migrate api-strbuf.txt into strbuf.h Jeff King
2015-01-16 9:04 ` [PATCH 1/7] strbuf.h: integrate api-strbuf.txt documentation Jeff King
2015-01-16 9:04 ` [PATCH 2/7] strbuf.h: unify documentation comments beginnings Jeff King
2015-01-16 9:05 ` Jeff King [this message]
2015-01-16 9:05 ` [PATCH 4/7] strbuf.h: format asciidoc code blocks as 4-space indent Jeff King
2015-01-16 9:05 ` [PATCH 5/7] strbuf.h: reorganize api function grouping headers Jeff King
2015-01-16 9:05 ` [PATCH 6/7] strbuf.h: drop boilerplate descriptions of strbuf_split_* Jeff King
2015-01-16 9:06 ` [PATCH 7/7] strbuf.h: group documentation for trim functions Jeff King
2015-02-12 23:01 ` [PATCH 0/7] migrate api-strbuf.txt into strbuf.h Junio C Hamano
2015-02-12 23:05 ` Jeff King
2015-02-16 22:41 ` Junio C Hamano
2015-02-17 23:00 ` Jonathan Nieder
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=20150116090510.GC31113@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=sbeller@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.