From: Eric Sunshine <sunshine@sunshineco.com>
To: Faiz Kothari <faiz.off93@gmail.com>
Cc: Git List <git@vger.kernel.org>, Johannes Sixt <j6t@kdbg.org>,
Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [PATCH v3 1/2] Introduce strbuf_write_or_die()
Date: Sun, 2 Mar 2014 15:05:39 -0500 [thread overview]
Message-ID: <CAPig+cQfbxX0oH_tfaQt5PT0DP29hRZ8seZdJ-ssLDQbH=iJGQ@mail.gmail.com> (raw)
In-Reply-To: <1393745664-21077-1-git-send-email-faiz.off93@gmail.com>
On Sun, Mar 2, 2014 at 2:34 AM, Faiz Kothari <faiz.off93@gmail.com> wrote:
> Signed-off-by: Faiz Kothari <faiz.off93@gmail.com>
Place your sign off below the commit message.
> Introduced a new function strbuf.c:strbuf_write_or_die()
> to the strbuf family of functions. Now use this API instead
> of write_or_die.c:write_or_die()
You want to explain what this patch is doing in imperative tone. Use
"Introduce" rather than "Introduced". The first sentence correctly
states what the patch is doing, however, the second sentence explains
what the next patch is doing, so it doesn't belong here. So, your
commit message for this patch might become:
Subject: strbuf: introduce strbuf_write_or_die()
Add strbuf convenience wrapper around lower-level write_or_die().
> ---
> Hi,
> Thanks for the suggestions and feedbacks.
> As Johannes Sixt pointed out, the function is now defined
> in strbuf.c and prototype added to strbuf.h
> Also, replaced if(!sbuf) with assert(sbuf) and split the patch into two
> as pointed out by Eric Sunshine.
Good explanation of what changed since the last attempt.
> As far as justification is concerned, I am not able to come up with
> a satisfactory justification. Apart from, that it makes life of the
> programmer a little easier and if we add a few more functions
> to thestrbuf API, we can make strbuf completely opaque. I am open
> to views and since I haven't used this API extensively, I cannot
> comment for what is missing and what is required. But I am going through it.
> Also, once this patch is OK, I'll add documentation for the API.
It's a good idea to add documentation when you add the function
itself, otherwise reviewers will have to wait yet another round to
review that addition. In this case, the documentation will likely be
one line, so it shouldn't be a particular burden to write it.
> Thanks again for the feedback.
>
> strbuf.c | 6 ++++++
> strbuf.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/strbuf.c b/strbuf.c
> index 83caf4a..337a70c 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -477,6 +477,12 @@ int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint)
> return len;
> }
>
> +void strbuf_write_or_die(const struct strbuf *sb, int fd)
> +{
> + assert(sb);
> + write_or_die(fd, sb->buf, sb->len);
> +}
Nice. Much better than previous versions of the patch.
> void strbuf_add_lines(struct strbuf *out, const char *prefix,
> const char *buf, size_t size)
> {
> diff --git a/strbuf.h b/strbuf.h
> index 73e80ce..6aadb6d 100644
> --- a/strbuf.h
> +++ b/strbuf.h
> @@ -156,6 +156,7 @@ extern size_t strbuf_fread(struct strbuf *, size_t, FILE *);
> /* XXX: if read fails, any partial read is undone */
> extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
> extern int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint);
> +extern void strbuf_write_or_die(const struct strbuf *sb, int fd);
> extern int strbuf_readlink(struct strbuf *sb, const char *path, size_t hint);
>
> extern int strbuf_getwholeline(struct strbuf *, FILE *, int);
> --
> 1.7.9.5
next prev parent reply other threads:[~2014-03-02 20:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-01 11:21 [PATCH] implemented strbuf_write_or_die() Faiz Kothari
2014-03-01 12:51 ` He Sun
2014-03-01 13:29 ` Faiz Kothari
2014-03-01 22:33 ` Michael Haggerty
2014-03-02 0:18 ` [PATCH v2] " Faiz Kothari
2014-03-02 2:47 ` Eric Sunshine
2014-03-02 2:55 ` Eric Sunshine
2014-03-02 7:34 ` [PATCH v3 1/2] Introduce strbuf_write_or_die() Faiz Kothari
2014-03-02 7:34 ` [PATCH v3 2/2] use strbuf_write_or_die() Faiz Kothari
2014-03-02 22:04 ` Eric Sunshine
2014-03-02 20:05 ` Eric Sunshine [this message]
2014-03-02 3:08 ` [PATCH] implemented strbuf_write_or_die() Eric Sunshine
2014-03-03 18:31 ` Junio C Hamano
[not found] ` <CAFbjVckhU7NHzLjqPo5WkoBwVLrOLg=CS6mHSKkQstUxB31_eA@mail.gmail.com>
2014-03-03 18:48 ` Fwd: " Faiz Kothari
2014-03-03 19:46 ` Eric Sunshine
2014-03-03 19:51 ` David Kastrup
2014-03-03 20:35 ` Junio C Hamano
2014-03-03 21:29 ` Eric Sunshine
2014-03-04 9:18 ` Michael Haggerty
2014-03-04 17:01 ` Faiz Kothari
2014-03-04 18:45 ` Junio C Hamano
2014-03-01 21:34 ` Johannes Sixt
2014-03-03 18:27 ` Junio C Hamano
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='CAPig+cQfbxX0oH_tfaQt5PT0DP29hRZ8seZdJ-ssLDQbH=iJGQ@mail.gmail.com' \
--to=sunshine@sunshineco.com \
--cc=faiz.off93@gmail.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=mhagger@alum.mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).