[PATCH] xsize_t: check whether we lose bits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx>
---

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]