Re: [PATCHv6 1/4] Read (but not write) from $XDG_CONFIG_HOME/git/config file

From: nguyenhu@minatec.inpg.fr <nguyenhu@minatec.inpg.fr>
Date: Jun 11, 2012, 22:59 UTC
Message-ID: <20120612005949.Horde.2Iy7T3wdC4BP1nhlOdxxKdA@webmail.minatec.grenoble-inp.fr>
In-Reply-To: <20120611185311.Horde.RALabXwdC4BP1iJ3aQ-w89A@webmail.minatec.grenoble-inp.fr>

nguyenhu@minatec.inpg.fr a écrit :

Show 23 quoted lines

> Junio C Hamano <gitster@pobox.com> a écrit :
>
>> Erik Faye-Lund <kusmabite@gmail.com> writes:
>>
>>> The awkward thing about doing this, is that the memory allocated by
>>> the strbuf cannot be reclaimed if you go with this. A pointer that has
>>> been adjusted (like cleanup_path can do) cannot be successfully fed to
>>> free.
>>
>> Yeah, I wouldn't recommend doing that.  Either
>>
>> 	path = strbuf_detach(&sb, NULL);
>> 	retval = xstrdup(cleanup_path(path));
>>        free(path);
>>        return retval;
>>
>> or
>>
>> 	path = xstrdup(cleanup_path(sb.buf));
>>        strbuf_release(&sb);
>>        return path;
>>
>> would be more sensible.

In our next patch, mkpathdup() function will be

char *mkpathdup(const char *fmt, ...)
{
	char *path;
	struct strbuf sb = STRBUF_INIT;
	va_list args;

	va_start(args, fmt);
	strbuf_vaddf(&sb, fmt, args);
	va_end(args);
	path = xstrdup(cleanup_path(sb.buf));

	strbuf_release(&sb);
	return path;
}

which looks like our previous proposal with xstrdup() and cleanup_path() functions at the right place.