apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] apr_filepath_merge
Date Sun, 28 Jul 2002 17:22:11 GMT
At 05:09 AM 7/28/2002, Sander Striker wrote:
>Hi,
>
>This patch is trying to solve the following problems:
>
>1)  apr_filepath_merge("", ".") returns "" instead of "."
>
>This is a one line fix, but needs to be reviewed in the win32
>case, since a check for "/. /" is missed due to this patch.

Strangely enough, the existing behavior is correct.  apr_filepath_merge
should always eliminate all identity and parent-identity objects.  It's a
canonicalization function, so it cannot allow ambiguity like that.

Once you've apr_filepath_merge'd a path, you EXPECT to be able to
use it as a basepath.  But the basepath is never parsed to collapse these
constructs, since it's presumed to be canonical.

Please don't change the existing behavior in that respect... if you want to
test for and treat the result "" as ".", or "./" or whatever... feel free, 
but the
existing behavior needs to remain.

>2)  apr_filepath_merge(".", "") returns "./"
>
>Is a bit harder.  I wanted the function to exit as early as
>possible, so after the basic checks we just copy basepath and
>exit if addpath == "".
>
>I wasn't sure how to incorporate this change in the win32
>function, since that is really a nasty piece of code.  If
>someone familiar with that code(wrowe?) could take a look at it,
>I would appreciate it.

Well, if the left hand side is "." then it remains dot.  that's why you
get this behavior.

Remember the LHS MUST be canonical or the results are a bit
unpredictable, as you noticed.

I would accept a patch that if the RHS is an empty string, the LHS
is returned.  That's about all of this patch that I could accept.

Bill


Mime
View raw message