[RFC/PATCH] fast-import: Fix compile warnings

Not on all platforms are size_t and unsigned long equivalent.
Since I do not know how portable %z is, I play safe, and just
cast the respective variables to unsigned long.

Signed-off-by: Johannes Schindelin <redacted>
---

	I have no idea how portable %z is, but there are so many
	experts on this list. Care to enlighten me?

 fast-import.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/fast-import.c b/fast-import.c
index bc95a0d..2813ceb 100644
--- a/fast-import.c
+++ b/fast-import.c

@@ -882,7 +882,8 @@ static int store_object(
 	SHA_CTX c;
 	z_stream s;
 
-	hdrlen = sprintf((char*)hdr,"%s %lu",type_names[type],datlen) + 1;
+	hdrlen = sprintf((char*)hdr,"%s %lu", type_names[type],
+		(unsigned long)datlen) + 1;
 	SHA1_Init(&c);
 	SHA1_Update(&c, hdr, hdrlen);
 	SHA1_Update(&c, dat, datlen);

@@ -1427,7 +1428,8 @@ static void *cmd_data (size_t *size)
 		while (n < length) {
 			size_t s = fread(buffer + n, 1, length - n, stdin);
 			if (!s && feof(stdin))
-				die("EOF in data (%lu bytes remaining)", length - n);
+				die("EOF in data (%lu bytes remaining)",
+					(unsigned long)(length - n));
 			n += s;
 		}
 	}

@@ -2028,7 +2030,8 @@ int main(int argc, const char **argv)
 	fprintf(stderr, "      marks:     %10ju (%10ju unique    )\n", (((uintmax_t)1) << marks->shift) * 1024, marks_set_count);
 	fprintf(stderr, "      atoms:     %10u\n", atom_cnt);
 	fprintf(stderr, "Memory total:    %10ju KiB\n", (total_allocd + alloc_count*sizeof(struct object_entry))/1024);
-	fprintf(stderr, "       pools:    %10lu KiB\n", total_allocd/1024);
+	fprintf(stderr, "       pools:    %10lu KiB\n",
+		(unsigned long)(total_allocd / 1024));
 	fprintf(stderr, "     objects:    %10ju KiB\n", (alloc_count*sizeof(struct object_entry))/1024);
 	fprintf(stderr, "---------------------------------------------------------------------\n");
 	pack_report();

-- 
1.5.0.rc3.2124.g3861-dirty

On 2/7/07, Johannes Schindelin [off-list ref] wrote:

        I have no idea how portable %z is, but there are so many
        experts on this list. Care to enlighten me?

IEEE Std 1003.1[1] mentions it, but I never was able to rely on it:
AIX, Solaris, QNX-libc at least didn't have it, last time I checked.
Micro$oft doesn't have it, of course.

[1] http://www.opengroup.org/onlinepubs/009695399/functions/fprintf.html

Johannes Schindelin [off-list ref] wrote:

Not on all platforms are size_t and unsigned long equivalent.
Since I do not know how portable %z is, I play safe, and just
cast the respective variables to unsigned long.

We do this elsewhere in Git.  blobs are using unsigned long in
sha1_file.c for their length; I chose to size_t in gfi as that's
what the type is for...  but then look at the mess.

I applied this patch to my tree and pushed it to repo.or.cz.
This last hunk:
 

was the only part that did not apply cleanly, but that was easily
fixed by tossing an extra tab at the start of each line, as this
hunk was shifted in one level by a recent commit that Junio has
not pushed out to master.

-- 
Shawn.