2013/6/25 Junio C Hamano <[email protected]>:
> Jiang Xin <[email protected]> writes:
>
>> After substitute path_relative() in quote.c with relative_path() from
>> path.c, parameters (such as len and prefix_len) are obsolete in function
>> quote_path_relative(). Remove unused parameters and change the order of
>> parameters for quote_path_relative() function.
>> ...
>> diff --git a/builtin/clean.c b/builtin/clean.c
>> index 04e39..f77f95 100644
>> --- a/builtin/clean.c
>> +++ b/builtin/clean.c
>> @@ -262,7 +262,7 @@ int cmd_clean(int argc, const char **argv, const char
>> *prefix)
>> if (remove_dirs(&directory, prefix, rm_flags,
>> dry_run, quiet, &gone))
>> errors++;
>> if (gone && !quiet) {
>> - qname =
>> quote_path_relative(directory.buf, directory.len, &buf, prefix);
>> + qname =
>> quote_path_relative(directory.buf, prefix, &buf);
>> printf(dry_run ? _(msg_would_remove) :
>> _(msg_remove), qname);
>
> This one needed a bit closer look to make sure directory.len is
> already pointing at the end of directory.buf (it is) to verify that
> this is a safe conversion. Everywhere else we lost either -1 or
> strlen() of the string we feed quote_path() and quote_path_relative()
> so they look fine.
When tracking in "remove_dirs(&directory, prefix, rm_flags, dry_run,
quiet, &gone)",
there are some suspect strbuf_setlens, like:
strbuf_setlen(path, len);
strbuf_addstr(path, e->d_name);
and at the end of remove_dirs, there is:
strbuf_setlen(path, original_len);
So both the but and len will be restored in the end, and directory.len always
points to strlen of directory.buf.
So it's safe for the following refactor:
- qname =
quote_path_relative(directory.buf, directory.len, &buf, prefix);
+ qname =
quote_path_relative(directory.buf, prefix, &buf);
--
Jiang Xin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
