From: Pierre Habouzit <madcoder@debian.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] New strbuf APIs: splice and embed.
Date: Sun, 16 Sep 2007 10:10:12 +0200 [thread overview]
Message-ID: <20070916081012.GA21810@artemis.corp> (raw)
In-Reply-To: <7vwsur77g7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]
On Sun, Sep 16, 2007 at 12:57:44AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > * strbuf_splice replace a portion of the buffer with another.
> > * strbuf_embed replace a strbuf buffer with the given one, that should be
> > malloc'ed. Then it enforces strbuf's invariants. If alloc > len, then this
> > function has negligible cost, else it will perform a realloc, possibly
> > with a cost.
>
> "embed" does not sound quite right, does it? It is a reverse
> operation of strbuf_detach() as far as I can tell.
Well I don't like either, and indeed strbuf_attach() seems better.
> > -void strbuf_rtrim(struct strbuf *sb)
> > -{
> > +void strbuf_rtrim(struct strbuf *sb) {
> > while (sb->len > 0 && isspace((unsigned char)sb->buf[sb->len - 1]))
> > sb->len--;
> > sb->buf[sb->len] = '\0';
>
> This is changing the style in the wrong direction, isn't it? We
> start our functions like this:
>
> type name(proto)
> {
Well that's what I usually do for my code, but I thought git was
putting the opening brace on the same line, my bad.
> > +void strbuf_splice(struct strbuf *sb, size_t pos, size_t len,
> > + const void *data, size_t dlen)
> > +{
> > + if (pos + len < pos)
> > + die("you want to splice outside from the buffer");
>
> That is a funny error message for an integer wrap-around check.
right ;)
>
> > + if (pos > sb->len)
> > + pos = sb->len;
>
> Shouldn't this be flagged as a programming error?
>
> > + if (pos + len > sb->len)
> > + len = sb->len - pos;
>
> Likewise.
I just attached the same semantics that was chose for strbuf_insert
when the insertion position is outside from the buffer. Though I can
enforce those to stay inside the buffer and just die(). I don't care
much I shall say. Maybe it hides some programmers being sloppy, hence is
a bad semantics. I'll propose a patch where the check die()s instead of
"fixing" the values.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-09-16 8:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-15 14:12 [RFC] strbuf's in builtin-apply Pierre Habouzit
2007-09-15 13:56 ` [PATCH] New strbuf APIs: splice and embed Pierre Habouzit
2007-09-16 0:57 ` Junio C Hamano
2007-09-16 8:10 ` Pierre Habouzit [this message]
2007-09-15 14:04 ` [PATCH] builtin-apply: use strbuf's instead of buffer_desc's Pierre Habouzit
2007-09-16 0:56 ` Junio C Hamano
2007-09-16 8:15 ` Pierre Habouzit
2007-09-15 17:07 ` [RFC] strbuf's in builtin-apply Pierre Habouzit
2007-09-16 17:21 ` Pierre Habouzit
2007-09-15 13:56 ` [PATCH] Now that cache.h needs strbuf.h, remove useless includes Pierre Habouzit
2007-09-15 13:56 ` [PATCH] New strbuf APIs: splice and attach Pierre Habouzit
2007-09-16 20:20 ` Florian Weimer
2007-09-16 20:51 ` Pierre Habouzit
2007-09-17 5:43 ` Florian Weimer
2007-09-15 21:50 ` [PATCH] Refactor replace_encoding_header Pierre Habouzit
2007-09-16 8:19 ` [PATCH] Remove preemptive allocations Pierre Habouzit
2007-09-16 13:51 ` [PATCH] Rewrite convert_to_{git,working_tree} to use strbuf's Pierre Habouzit
2007-09-16 18:27 ` Linus Torvalds
2007-09-16 16:54 ` [PATCH] builtin-apply: use strbuf's instead of buffer_desc's Pierre Habouzit
2007-09-16 17:28 ` [RFC] strbuf's in builtin-apply Pierre Habouzit
2007-09-16 22:54 ` 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=20070916081012.GA21810@artemis.corp \
--to=madcoder@debian.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.