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

[RFC] strbuf's in builtin-apply

From
Pierre Habouzit <madcoder@debian.org>
Date
Sep 15, 2007, 14:12 UTC
Message-ID
<20070915141210.GA27494@artemis.corp>
  I promised it, here it comes. It comes though with some possible
problems, so I'd like to see them discussed first.
  builtin-apply.c was messing with its custom buffers a lot,
reallocating the buffers and so on, hence I had to create strbuf_embed
to have a strbuf-safe API doing exactly the same. Though, because of the
"I want an extra NUL in the end"-invariant, this can come with a quite
high price. in the second patch, there is a hunk:

- nsize = got; - nbuf = convert_to_git(path, buf, &nsize); - if (nbuf) { - free(buf); - *buf_p = nbuf; - *alloc_p = nsize; - *size_p = nsize; - } - return got != size; + + nsize = buf->len; + nbuf = convert_to_git(path, buf->buf, &nsize); + if (nbuf) + strbuf_embed(buf, nbuf, nsize, nsize); + return 0;

  Here, I've not been able to check if convert_to_git was in fact always
dealing with a NUL-terminated buffer (That would be in fact nsize+1) or
not, hence here this strbuf_embed will likely perform a realloc. I don't
know git enough to know if this can become an horrible burden though.
  Another suspicious hunk is:
-	data = (void*) fragment->patch;
[...]
 	case BINARY_LITERAL_DEFLATED:
-		free(desc->buffer);
-		desc->buffer = data;
-		dst_size = fragment->size;
-		break;
+		strbuf_embed(buf, fragment->patch, fragment->size, fragment->size);
+		return 0;
  TTBOMK the ->patch pointer is a pointer inside a buffer, not a buffer
that has been malloc'ed (and there are code paths before my patch that
would still realloc the buffer so I don't think I introduce an issue).
It passes the test-suite without crashing, but well, maybe this should
be a copy instead.
  The rest is pretty straightforward.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Next: Pierre Habouzit
Message 1 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.