Re: [PATCH] hex.c: reduce memory footprint of sha1_to_hex static buffers

Stefan Beller [off-list ref] writes:

On Fri, Feb 13, 2015 at 1:41 PM, Junio C Hamano [off-list ref] wrote:

quoted

Stefan Beller [off-list ref] writes:

quoted

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 ;-)

I don't think it's a bug, it's just wasting memory?

Yes and no ;-)  As I already said above, 50 "is" just an arbitrary
number that is round and enough to hold 40 bytes with trailing NUL,
and the waste does not lead to behaviour that is different from what
was intended, of course, so it would not crash.

However, the wastage was bothersome enough to make you send a patch,
so you can call it a "bug".  It was wasting readers time ;-)