Karl Fogel <email@example.com> writes:
> Eric Gillespie <firstname.lastname@example.org> writes:
> > That's similar to what i originally thought. I thought it must
> > be a bug that a NULL ever made it to check_path. But i looked in
> > repos_to_repos_copy, and it treats NULL as if it is a perfectly
> > reasonable value to have (by doing some manipulation on the path
> > if it isn't NULL and not signalling an error if it is). I also
> > looked at ra_dav's check_path and see that it also treats NULL as
> > acceptable. Based on that evidence i concluded that it is legal
> > to pass a NULL to check_path.
> > If that is deemed incorrect, i can provide a patch fixing all
> > check_path callers.
> The latter sounds better to me too (conservatively, of course -- that
> is, if the path "shouldn't" be null in the caller anyway, then add no
> check). Thanks, Eric.
Well, assuming svn_path_join and svn_path_uri_decode never return
NULL, this turns out to be the only place where check_path is
called with a NULL. I know that svn_path_uri_decode *does*
return NULL if you pass NULL to it, but every place where the
svn_path_uri_decode return value is passed to check_path never
passes NULL to svn_path_uri_decode.
So, surprisingly enough, the new patch is just as small as the
old one. I have included it here as well as in the issue. If
this patch looks correct, i'll write up a log message for it.
--- subversion/libsvn_client/copy.c (revision 4395)
+++ subversion/libsvn_client/copy.c (working copy)
@@ -228,6 +228,8 @@
"error decomposing relative path `%s'", src_rel);
+ src_rel = "";
dst_rel = svn_path_is_child (top_url, dst_url, pool);
@@ -239,6 +241,8 @@
"error decomposing relative path `%s'", dst_rel);
+ dst_rel = "";
/* Allocate room for the root baton, the pieces of the
source's or destination's path, and the destination itself. */
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jan 15 21:29:02 2003