Brandon Williams <bmwill@xxxxxxxxxx> writes:
> On 12/12, Junio C Hamano wrote:
> ...
>> E.g. for input path "foo/bar/", the above loop runs zero times and
>> then ...
>>
>> > + /* Skip sequences of multiple path-separators */
>> > + while (offset < len && is_dir_sep(path->buf[len - 1]))
>> > + len--;
>>
>> ... the slash at the end is removed, leaving "foo/bar" in path.
>
> The way this is currently used I don't believe this scenario can happen
> (since input to this shouldn't have trailing slashes), but if others
> begin to use this function then yes, that is an implicit assumption.
OK.
>> > + /* Iterate over the remaining path components */
>> > + while (remaining.len > 0) {
>> > + get_next_component(&next, &remaining);
>> > +
>> > + if (next.len == 0) {
>> > + continue; /* empty component */
>> > + } else if (next.len == 1 && !strcmp(next.buf, ".")) {
>> > + continue; /* '.' component */
>> > + } else if (next.len == 2 && !strcmp(next.buf, "..")) {
>> > + /* '..' component; strip the last path component */
>> > + strip_last_component(&resolved);
>>
>> Wouldn't this let "resolved" eventually run out of the path
>> components to strip for a malformed input e.g. "/a/../../b"?
>
> As I understand it, that path is correct and would resolve to "/b".
That is OK on the traditional UNIX end.
I am not sure if we want to handle the "//host/share/$remaining" in
this codepath, though. If we do, then this is still an issue (IIRC,
somebody explained that we do not want to step into //host/share/
part when seeing ".."---we'd at least need to leave a NEEDSWORK
comment so that interested parties can later take a look into it.