Re: [RESEND] [PATCH] Endianness bug in index cache logic

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 27, 2009, 18:24 UTC
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:

Show 17 quoted lines

> 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?).