On 11/20/2018 12:04 AM, tboegi@xxxxxx wrote:
From: Torsten Bögershausen <tboegi@xxxxxx>
Currently the length of data which is stored in memory is stored
in "unsigned long" at many places in the code base.
This is OK when both "unsigned long" and size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64 bit Windows system am "unsigned long" is 32 bit, and
that may be too short to measure the size of objects in memory,
a size_t is the natural choice.
Is this change enough to store 4GB files on Windows? Or is there more to
do?
Thanks for all the comments on V1.
Changes since V1:
- Make the motivation somewhat clearer in the commit message
- Rebase to the November 19 pu
What we really need for this patch to fly are this branches:
mk/use-size-t-in-zlib
tb/print-size-t-with-uintmax-format
I believe communicating these direct dependencies is the correct way to
go, and the rebase you mentioned is unnecessary (instead, test with a
merge).
Hopefully the patch applies on top of a merge of those branches.
@@ -529,7 +530,7 @@ static void *unpack_raw_entry(struct object_entry *obj,
}
static void *unpack_data(struct object_entry *obj,
- int (*consume)(const unsigned char *, unsigned long, void *),
+ int (*consume)(const unsigned char *, size_t, void *),
void *cb_data)
This is the only instance that is not paired directly with a variable
name like "size", "sz", or "len". However, it appears to be correct from
context.
Thanks for this!
Reviewed-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
