Re: [PATCH] Avoid bug in Solaris xpg4/sed as used in submodule

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 9, 2012, 18:44 UTC
Message-ID: <7vbon0wxqs.fsf@alter.siamese.dyndns.org>
In-Reply-To: <m2fwcdc57q.fsf@igel.home>

Andreas Schwab <schwab@linux-m68k.org> writes:

Show 25 quoted lines

> Ben Walton <bwalton@artsci.utoronto.ca> writes:
>
>> Excerpts from Andreas Schwab's message of Mon Apr 09 02:40:03 -0400 2012:
>>
>>> How about using 's|[^/][^/]*|..|g' instead, which should avoid the bug
>>> as well.
>>
>> I'd be ok with that change if the changed semantics of the regex are
>> ok in this application.  It's essentially the same as s|[^/]+|..|g,
>> which requires at least one character.
>>
>> In the current code, if you do:
>>
>> echo '/' | sed -e 's|[^]*|..|g'
>>
>> you get: ../.. (from a working implementation).
>>
>> Your regex would see the result  be: /
>>
>> I don't think we'd ever be passing a plain /, but we might pass a
>> fully qualified path /path/to/foo, which would see the result change
>> from ../../../.. to /../../.. and that could have unintended impact.
>
> AFAICS the variables at this point never contain a value with a leading
> slash.

Correct. After $a and $b are initialized to "$(cd somewhere ; pwd)/", there is a loop:

	while test "${a%%/*}" = "${b%%/*}"
	do
		a=${a#*/}
		b=${b#*/}
	done

The test for the first iteration will see that they both start with '/' so stripping maximal trailing substring that match "/*" from them will yield two empty strings, and we always enter the body of the loop. The body during the first iteration will strip the leading '/'.

When pwd computed for both $a and $b were at '/', this loop may do something funky ($b will become empty), but that is covered by an earlier "is $a inside $b or vice versa?" check, so we should be OK.