惠轶群 writes:
> For example:
>
> const char *enter_repo(const char *path, int strict)
> {
> static struct strbuf validated_path = STRBUF_INIT;
> static struct strbuf used_path = STRBUF_INIT;
>
> if (!path)
> return NULL; // no need to
2016-03-28 22:50 GMT+08:00 Junio C Hamano :
> 惠轶群 writes:
>
>> After read the source code of strbuf more carefully, I get the conclusion
>> that if a strbuf is initialized with STRBUF_INIT but is not used, there is
>> no need to release it. Is it true?
>
>
惠轶群 writes:
> After read the source code of strbuf more carefully, I get the conclusion
> that if a strbuf is initialized with STRBUF_INIT but is not used, there is
> no need to release it. Is it true?
If it is initialized with STRBUF_INIT and never used, there is no
reason
惠轶群 writes:
> Excuse me, but I could not find
> `Documentation/technical/api-strbuf.txt` in master branch. Do you
> refer to the header of `strbuf.h`? In which, I learnt how to
> initialize the strbuf and how to take use of it when I began to
> use it.
Ah, yes, it was a
2016-03-26 1:59 GMT+08:00 Jeff King :
> On Fri, Mar 25, 2016 at 10:21:48PM +0800, 惠轶群 wrote:
>
>> > There are some minor English problems here (and elsewhere). E.g., you
>> > probably want "So we just issue a warning and leave it to the user to
>> > solve.".
>>
>> Sorry for my
2016-03-26 0:55 GMT+08:00 Junio C Hamano :
> 惠轶群 writes:
>
>>> There's a lot of "what" here that the caller doesn't really care about,
>>> and which may go stale with respect to the implementation over time. Can
>>> we make something more succinct like:
>>>
Jeff King writes:
>> > That's clearer, but if I were the caller, I would worry about the
>> > security of the path.
>> > How about adding:
>> >
>> > The security of the path is ensured by file permission.
>>
>> Is "by file permission" descriptive enough?
>>
>> To protect
On Fri, Mar 25, 2016 at 10:21:48PM +0800, 惠轶群 wrote:
> > There are some minor English problems here (and elsewhere). E.g., you
> > probably want "So we just issue a warning and leave it to the user to
> > solve.".
>
> Sorry for my English.
Thanks. And sorry if that sounded too harsh. I know
On Fri, Mar 25, 2016 at 09:55:59AM -0700, Junio C Hamano wrote:
> 惠轶群 writes:
>
> >> There's a lot of "what" here that the caller doesn't really care about,
> >> and which may go stale with respect to the implementation over time. Can
> >> we make something more succinct
惠轶群 writes:
>> There's a lot of "what" here that the caller doesn't really care about,
>> and which may go stale with respect to the implementation over time. Can
>> we make something more succinct like:
>>
>> /*
>>* Return a path suitable for writing run-time files
> I find there are some similar leakage in this file. I'll fix them in
> another patch.
>
> Do you think we need some additional comments for the release of strbuf?
For example, in strbuf.h.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
2016-03-25 17:59 GMT+08:00 Jeff King :
> On Wed, Mar 23, 2016 at 06:13:22PM +0800, Hui Yiqun wrote:
>
>> +/**
>> + * this function does the following:
>> + *
>> + * 1. if $XDG_RUNTIME_DIR is non-empty, `$XDG_RUNTIME_DIR/git` is used in
>> next
>> + * step, otherwise `/tmp/git-$uid`
On Wed, Mar 23, 2016 at 06:13:22PM +0800, Hui Yiqun wrote:
> +/**
> + * this function does the following:
> + *
> + * 1. if $XDG_RUNTIME_DIR is non-empty, `$XDG_RUNTIME_DIR/git` is used in
> next
> + * step, otherwise `/tmp/git-$uid` is taken.
> + * 2. ensure that above directory does exist.
This function is aimed to provide an uniform location to put
runtime files according to the xdg base dir spec[1] and stop using
$HOME. On the other hand, the safety is considered(with directory
permission).
This function will use `$XDG_RUNTIME_DIR/git` if XDG_RUNTIME_DIR exists,
otherwise
14 matches
Mail list logo