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

Re: [PATCH] New strbuf APIs: splice and embed.

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 16, 2007, 00:57 UTC
Message-ID
<7vwsur77g7.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20070915141335.ECB4B4C152@madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
Show 5 quoted lines
> * 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.

Show 6 quoted lines
> -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)
        {
        	...
Show 5 quoted lines
> +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.
> +	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.

By the way, this is the kind of situation I wish everybody wrote their comparison in textual order. I had to draw a picture like this to see what was going on.

        sb->buf
        xxxxxxxxxxxzzzzzxxxxxxxxxxx\0
        ^                         ^
        0                   sb->len
                   ^    ^               ^    ^        
                   pos  pos+len         pos  pos+len  
                   v                    v
                   yyyyyyyyyy           yyyyyyyyyy    
                             ^                    ^   
                             dlen                 dlen
                   -------------        --------------
                   pos < sb->len        sb->len < pos
Previous: Pierre HabouzitNext: Pierre Habouzit
Message 3 of 21 in “[RFC] strbuf's in builtin-apply”
  1. Pierre HabouzitSep 15, 2007
  2. New strbuf APIs: splice and embed.Pierre Habouzit, Sep 15, 2007
  3. Junio C HamanoSep 16, 2007
  4. Pierre HabouzitSep 16, 2007
  5. builtin-apply: use strbuf's instead of buffer_desc's.Pierre Habouzit, Sep 15, 2007
  6. Junio C HamanoSep 16, 2007
  7. Pierre HabouzitSep 16, 2007
  8. Pierre HabouzitSep 15, 2007
  9. Pierre HabouzitSep 16, 2007
  10. New strbuf APIs: splice and attach.Pierre Habouzit, Sep 15, 2007
  11. Florian WeimerSep 16, 2007
  12. Pierre HabouzitSep 16, 2007
  13. Florian WeimerSep 17, 2007
  14. Now that cache.h needs strbuf.h, remove useless includes.Pierre Habouzit, Sep 15, 2007
  15. Refactor replace_encoding_header.Pierre Habouzit, Sep 15, 2007
  16. Remove preemptive allocations.Pierre Habouzit, Sep 16, 2007
  17. Rewrite convert_to_{git,working_tree} to use strbuf's.Pierre Habouzit, Sep 16, 2007
  18. Linus TorvaldsSep 16, 2007
  19. builtin-apply: use strbuf's instead of buffer_desc's.Pierre Habouzit, Sep 16, 2007
  20. Pierre HabouzitSep 16, 2007
  21. Junio C HamanoSep 16, 2007

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.