Re: [PATCH 17/38] resolve_gitlink_ref(): avoid memory allocation in many cases

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

 



On 06/07/2016 07:29 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> 
>> If we don't have to strip trailing '/' from the submodule path, then
>> don't allocate and copy the submodule name.
> 
> Makes sense.
> 
>>  int resolve_gitlink_ref(const char *path, const char *refname, unsigned char *sha1)
>>  {
>> -	int len = strlen(path);
>> -	struct strbuf submodule = STRBUF_INIT;
>> +	size_t len, orig_len = strlen(path);
>>  	struct ref_store *refs;
>>  	int flags;
>>  
>> -	while (len && path[len-1] == '/')
>> -		len--;
>> +	for (len = orig_len; len && path[len - 1] == '/'; len--)
>> +		;
>> +
>>  	if (!len)
>>  		return -1;
>>  
>> -	strbuf_add(&submodule, path, len);
>> -	refs = get_ref_store(submodule.buf);
>> -	strbuf_release(&submodule);
>> +	if (len == orig_len) {
> 
> You can keep the original while (), without introducing orig_len,
> and check if path[len] is NUL, which would probably be an end result
> that is easier to read.

OK, I'll change it.

>> +		refs = get_ref_store(path);
>> +	} else {
>> +		char *stripped = xmemdupz(path, len);
>> +
>> +		refs = get_ref_store(stripped);
>> +		free(stripped);
> 
> An alternative might be to add get_ref_store_counted() that takes
> (path, len) instead of NUL-terminated path, which does not look too
> bad looking at the state after applying all 38 patches.

This slash-stripping code was introduced in 2007 (0ebde32c87) and it's
not my priority to improve it as part of this patch series.

Michael

--
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]