Re: path canonicalization problem (issue #559)

On Mon, Jan 21, 2002 at 10:44:01PM +0000, Philip Martin wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>...
> > + /* if this is a url, we want to start condensing at the third slash,
> > + otherwise we start at the beginning of the path */
> > + if (svn_path_is_url ((const svn_string_t *)path))
>
> This cast relies on the members of svn_string_t being ordered the same
> as svn_stringbuf_t. It's true at present, but is it guaranteed?

There is NO such guarantee. The structures are and should be treated
completely independently.

The two structures should never be casted from one to the other. The best
change here is like what Karl said: create a local svn_string_t structure.

>...
> > + strcpy (tmp, tmp + 1);
>
> Can paths contain null characters?

No. Some of the changes that I've been making recently is to convert path
arguments from 'svn_stringbuf_t *' over to 'const char *'. (property names
also become null-term strings)

Subversion won't use paths with null characters in them. For "funny"
character sets in the filesystem, we'll translate to UTF-8 and use that
internally. UTF-8 doesn't have any embedded nulls.

> Not on Linux, but what about other
> platforms? That's why svn_stringbuf_t has a len member. Better not to
> use strstr/strcpy.

stringbuf has a len because it can represent binary data. In some cases, we
use it for representing regular data because it is also a "buffer" which can
be manipulated.

In this case, the fact that a path has a length is historical, rather than a
required sematnic.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org