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

Re: [PATCH V2 3/3] strbuf: allow to use preallocated memory

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 7, 2016, 18:10 UTC
Message-ID
<xmqqziqwq395.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20160607090653.GA4665@Messiaen>
William Duclot <william.duclot@ensimag.grenoble-inp.fr> writes:
Show 8 quoted lines
>> Perhaps I made it clearer by using a more exaggerated example e.g. a
>> typical expected buffer size of 128 bytes, but the third line of
>> 1000 line input file was an anomaly that is 200k bytes long.  I do
>> not want to keep that 200k bytes after finishing to process that
>> third line while using its initial 80 bytes for the remaining 977
>> lines.
>
> "its initial 128 bytes", rather than "its initial 80 bytes", no?

Either way would work, but 80 is closer to what I had in mind, as the set-up of the example is "I know 99% of my input will fit within 80, but I'll allocate 128 to avoid realloc cost when there are rare ones that bust 80. I do not want to die only because there is an occasional oddball that needs 200".

Show 16 quoted lines
> The "fixed" feature was aimed to allow the users to use strbuf with
> strings that they doesn't own themselves (a function parameter for
> example). From Michael example in the original mail:
>
> void f(char *path_buf, size_t path_buf_len)
> {
>     struct strbuf path;
>     strbuf_wrap_fixed(&path, path_buf,
>     strlen(path_buf),
>     path_buf_len);
>     ...
>     /*
>      * no strbuf_release() required here, but if called it
>      * is a NOOP
>      */
> }
Think what does the "..." part would do using the "path" strbuf.

If 'f()' is meant to take the "dying is perfectly fine if the data we have to process exceeds the area we were given even by one byte" attitude, then the "capped to the same length as allocated" is perfectly fine, but if 'f()' cannot afford to die() and instead has to signal an error condition to its caller, then this function has to check the length currently in use (i.e. path.len) and how much more memory it can still use, before making each call to strbuf_*() functions, no?

If we were to add "fixed" feature, we'd want to see it to help a function like f() that cannot afford to die() and does not want to malloc()/realloc(). I do not think what was in this series was it.

Previous: William DuclotNext: Michael Haggerty
Message 18 of 32 in “strbuf: improve API”
  1. 0/3 strbuf: improve APIWilliam Duclot, Jun 6, 2016
  2. 1/3 strbuf: add testsWilliam Duclot, Jun 6, 2016
  3. Matthieu MoyJun 6, 2016
  4. Johannes SchindelinJun 7, 2016
  5. 2/3 pretty.c: rename strbuf_wrap() functionWilliam Duclot, Jun 6, 2016
  6. Matthieu MoyJun 6, 2016
  7. Johannes SchindelinJun 7, 2016
  8. 3/3 strbuf: allow to use preallocated memoryWilliam Duclot, Jun 6, 2016
  9. Matthieu MoyJun 6, 2016
  10. Junio C HamanoJun 6, 2016
  11. William DuclotJun 6, 2016
  12. Junio C HamanoJun 6, 2016
  13. Jeff KingJun 6, 2016
  14. Junio C HamanoJun 6, 2016
  15. Junio C HamanoJun 6, 2016
  16. Jeff KingJun 6, 2016
  17. William DuclotJun 7, 2016
  18. Junio C HamanoJun 7, 2016
  19. Michael HaggertyJun 8, 2016
  20. Junio C HamanoJun 8, 2016
  21. Jeff KingJun 8, 2016
  22. send-pack: use buffered I/O to talk to pack-objectsJeff King, Jun 8, 2016
  23. Matthieu MoyJun 9, 2016
  24. Ramsay JonesJun 9, 2016
  25. Jeff KingJun 9, 2016
  26. Ramsay JonesJun 9, 2016
  27. Junio C HamanoJun 9, 2016
  28. Jeff KingJun 9, 2016
  29. Matthieu MoyJun 9, 2016
  30. Junio C HamanoJun 8, 2016
  31. Jeff KingJun 8, 2016
  32. Junio C HamanoJun 8, 2016

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.