From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 27 Dec 2009 18:24:00 GMT
Subject: Re: [RESEND] [PATCH] Endianness bug in index cache logic
Message-ID: <7veimgxolb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091227061121.GP14941@gradx.cs.jhu.edu>

Nathaniel W Filardo <nwf@cs.jhu.edu> writes:

> I got some free time and tracked it down.  The following one-line delta
> fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
> the wrong endianness for the memcpy trick to work as written?  I could be
> sligntly off in my assessment of the problem, tho'.
>
> index 1bbaf1c..9033dd3 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
>                  * extension name (4-byte) and section length
>                  * in 4-byte network byte order.
>                  */
> -               unsigned long extsize;
> +               uint32_t extsize;
>                 memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
>                 extsize = ntohl(extsize);
>                 if (read_index_extension(istate,

Good catch.

The original is broken on big endian 64-bit platforms, and your sparc64
indeed is one.  The code expects to see a signature (4-byte) at src_offset
followed by length (4-byte int in network byte order) and it is trying to
read read the latter in extsize.

Thanks for the fix.  The bug dates back to late April 2006, and I am kind
of surprised that nobody reported this since then (perhaps nobody runs git
on big endian 64-bit boxes?).