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

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

 



On Sun, Jun 10, 2012 at 3:48 PM,  <nguyenhu@xxxxxxxxxxxxxxx> wrote:
>
> Junio C Hamano <gitster@xxxxxxxxx> a écrit :
>
>>> 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 = strbuf_detach(&sb, NULL);
>>>
>>>        strbuf_release(&sb);
>>>        return path;
>>> }
>>
>>
>> I didn't mean to suggest removing the call to clean-up-path
>> function.  What I meant was that strbuf_detach() is a way to take
>> the ownership of the buffer, so that you do not have to call
>> strbuf_release() on it.
>
>
> So with the call to clean-up-path function and without the call to
> strbuf_release(), mkpathdup() function becomes :
>
>
> char *mkpathdup(const char *fmt, ...)
> {
>        struct strbuf sb = STRBUF_INIT;
>        va_list args;
>
>        va_start(args, fmt);
>        strbuf_vaddf(&sb, fmt, args);
>        va_end(args);
>
>        return cleanup_path(strbuf_detach(&sb, NULL));
>
> }

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