[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1448810 - in /subversion/trunk/subversion: include/private/svn_fs_util.h libsvn_fs_fs/tree.c libsvn_fs_util/fs-util.c

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 21 Feb 2013 16:41:00 -0500

On 02/21/2013 04:32 PM, stefan2_at_apache.org wrote:
> Modified: subversion/trunk/subversion/include/private/svn_fs_util.h
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/include/private/svn_fs_util.h?rev=1448810&r1=1448809&r2=1448810&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/include/private/svn_fs_util.h (original)
> +++ subversion/trunk/subversion/include/private/svn_fs_util.h Thu Feb 21 21:32:26 2013
> @@ -37,14 +37,16 @@
> extern "C" {
> #endif /* __cplusplus */
>
> -/* Return a canonicalized version of a filesystem PATH, allocated in
> - POOL. While the filesystem API is pretty flexible about the
> - incoming paths (they must be UTF-8 with '/' as separators, but they
> - don't have to begin with '/', and multiple contiguous '/'s are
> - ignored) we want any paths that are physically stored in the
> - underlying database to look consistent. Specifically, absolute
> - filesystem paths should begin with '/', and all redundant and trailing '/'
> - characters be removed.
> +/* If the filesystem PATH is not already in canonical form, return a
> + canonicalized version of it, allocated in POOL. Otherwise, return
> + PATH directly.
> +
> + While the filesystem API is pretty flexible about the incoming paths
> + (they must be UTF-8 with '/' as separators, but they don't have to
> + begin with '/', and multiple contiguous '/'s are ignored) we want any
> + paths that are physically stored in the underlying database to look
> + consistent. Specifically, absolute filesystem paths should begin with
> + '/', and all redundant and trailing '/' characters be removed.

Hrm, in my experience this construct -- *maybe* allocating a returned value
in the provided pool, maybe not -- eventually leads to subtle problems
and/or redundant stringdup's (by callers who need to guarantee a particular
pool lifetime). I much prefer the simpler promise that the returned path is
allocated from the provided pool.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-02-21 22:41:49 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.