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

Re: [PATCH] Change strbuf_read_file() to return ssize_t

From
Jeff King <peff@peff.net>
Date
Jul 7, 2015, 14:33 UTC
Message-ID
<20150707143350.GB629@peff.net>
In-Reply-To
<74f6ccbe74486b1d5589e953c4cf6d39c82c5c05.1435931485.git.mhagger@alum.mit.edu>
On Fri, Jul 03, 2015 at 03:59:32PM +0200, Michael Haggerty wrote:
Show 13 quoted lines
> It is currently declared to return int, which could overflow for large
> files.
> 
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> This patch is against maint, but it also rebases against master
> without conflict.
> 
> I couldn't find any way to exploit this bug. Most callers only use
> this function for locally-generated files in the first place. And the
> correct length of the file is available in strbuf::len, so most
> callers only use the return value for a "< 0" check. And they don't do
> anything risky on the error path.

FWIW, I also looked for problem areas, but couldn't find anything interesting. But this seems like an obviously good thing to be doing anyway.

I also wondered if any callers needed to adjust their storage for the return type to ssize_t (i.e., are we just moving the truncation up one assignment). But there is only a single caller that assigns the result, and it uses an ssize_t already.

-Peff
Previous: Michael Haggerty
Message 2 of 2 in “Change strbuf_read_file() to return ssize_t”
  1. Change strbuf_read_file() to return ssize_tMichael Haggerty, Jul 3, 2015
  2. Jeff KingJul 7, 2015

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.