Web lists-archives.com

Re: [PATCH v2 1/1] Use size_t instead of 'unsigned long' for data in memory

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:

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>