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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 13, 2015 at 1:41 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> 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 ;-)

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

As I could not find any documentation on the
magical 50 in the early days, I cc'd Linus
in case there is something I did not think of yet.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]