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

Re: [PATCH] strbuf: release memory on read error in strbuf_read_once()

From
Jeff King <peff@peff.net>
Date
Dec 7, 2017, 21:28 UTC
Message-ID
<20171207212855.GE12850@sigill.intra.peff.net>
In-Reply-To
<6a39662f-8ff2-c314-5348-4189737a6853@web.de>
On Thu, Dec 07, 2017 at 09:51:26PM +0100, René Scharfe wrote:
Show 8 quoted lines
> If other strbuf add functions cause the first allocation and
> subsequently encounter an error then they release the memory, restoring
> the pristine state of the strbuf.  That simplifies error handling for
> callers.
> 
> Do the same in strbuf_read_once(), and do it also in case no bytes were
> read -- which may or may not be an error as well, depending on the
> caller.
Makes sense, and the patch is delightfully simple.

For the "0" case nobody should be negatively impacted by dropping the allocation, as they get a sane 0-length string from the slopbuf (and anybody who relies on sb->buf being allocated without calling detach or similar is already doing it wrong).

-Peff
Previous: René Scharfe
Message 2 of 2 in “strbuf: release memory on read error in strbuf_read_once()”
  1. strbuf: release memory on read error in strbuf_read_once()René Scharfe, Dec 7, 2017
  2. Jeff KingDec 7, 2017

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.