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

[PATCH] xsize_t: check whether we lose bits

From
Thomas Rast <trast@student.ethz.ch>
Date
Jul 28, 2010, 16:36 UTC
Message-ID
<a619b6d672b4d01ce4107566267ba9b67904652b.1280334553.git.trast@student.ethz.ch>

Attempting to mmap (via git-add or similar) a file larger than 4GB on 32-bit Linux systems results in a repository that has only the file modulo 4GB stored, because of truncation of the off_t file size to a size_t for mmap.

When xsize_t was introduced to handle this truncation in dc49cd7 (Cast 64 bit off_t to 32 bit size_t, 2007-03-06), Shawn even pointed out that it should detect when such a cutoff happens.

Make it so.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

Of course this does not fix the underlying issue that we want to mmap the file, so you still cannot add them.

Also, I must be missing something, this patch is way too simple.
 git-compat-util.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 02a73ee..fe845ae 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -388,6 +388,8 @@ extern int odb_pack_keep(char *name, size_t namesz, unsigned char *sha1);
 
 static inline size_t xsize_t(off_t len)
 {
+	if (len > (size_t) len)
+		die("Cannot handle files this big");
 	return (size_t)len;
 }
 
-- 
1.7.2.349.gd5452
Message 1 of 1 in “xsize_t: check whether we lose bits”
  1. xsize_t: check whether we lose bitsThomas Rast, Jul 28, 2010

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.