Stefan Beller <sbel...@google.com> writes:

> 41 bytes is the exact number of bytes needed for having the returned
> hex string represented. 50 seems to be an arbitrary number, such
> that there are no benefits from alignment to certain address boundaries.

Yes, with s/seems to be/is/;

This comes from e83c5163 (Initial revision of "git", the information
manager from hell, 2005-04-07), and when dcb3450f (sha1_to_hex()
usage cleanup, 2006-05-03) introduced the "4 recycled buffers" on
top, the underlying array was left at 50 bytes long.

You can now have "I fixed Linus's bug" badge ;-)

> Signed-off-by: Stefan Beller <sbel...@google.com>
> ---
>  hex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hex.c b/hex.c
> index 9ebc050..cfd9d72 100644
> --- a/hex.c
> +++ b/hex.c
> @@ -59,7 +59,7 @@ int get_sha1_hex(const char *hex, unsigned char *sha1)
>  char *sha1_to_hex(const unsigned char *sha1)
>  {
>       static int bufno;
> -     static char hexbuffer[4][50];
> +     static char hexbuffer[4][41];
>       static const char hex[] = "0123456789abcdef";
>       char *buffer = hexbuffer[3 & ++bufno], *buf = buffer;
>       int i;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to