Junio C Hamano [off-list ref] writes:
I'd rather see the function lose the NUL termination; if that makes the
behaviour inconsistent with its name, perhaps it is better to rename the
function; perhaps xmalloc1() to denote that it overallocates by one?
Actually I take that back---all the callers do benefit from the allocator
giving a buffer that is pre-terminated with NUL.
We can also lose "buf[size] = 0" from unpack_sha1_rest() patch.
On Tue, Jan 26, 2010 at 12:52:00PM -0800, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
I'd rather see the function lose the NUL termination; if that makes the
behaviour inconsistent with its name, perhaps it is better to rename the
function; perhaps xmalloc1() to denote that it overallocates by one?
Actually I take that back---all the callers do benefit from the allocator
giving a buffer that is pre-terminated with NUL.
We can also lose "buf[size] = 0" from unpack_sha1_rest() patch.
If that line would be next to xmalloc() line, I would have removed it, but
because it was beyound loop, I was worried that something might be done
to it (and was not in right mood to analyze the logic properly).
And yeah, that nul-termination in xmemdupz is not needed. Oops, missed
that.
-Ilari