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

Re: Another type issue.

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-02-27 08:23:51 CET

On Mon, Feb 26, 2001 at 05:01:51PM -0500, Greg Hudson wrote:
> We should use svn_string_t whenever:
>
> * We are passing a mutable string, or
> * We need to represent binary data (including 0 bytes)
>
> We should use char * whenever the above aren't true, i.e. when we're
> passing an immutable string which can only contain text data.
>
> ---
> That's my position. Some rationale:
>
> We could use svn_string_t everywhere. It would be kind of a pain in
> the butt (because we'd have to convert every time we wanted to use a
> system call or apr string-handling routine, and because we'd have to
> worry about memory allocation even when we were just passing a
> literal), but it would work. But we've rejected that approach.
>
> Frankly, I think it's a tiny bit unclean to pass an svn_string_t * for
> an immutable string when we are representing binary data. But blame C
> for using a half-assed string type for that gaffe. A "const"
> qualifier will make it clear that the called function isn't allowed to
> modify the string.

I'm with Greg on this one. There are a couple lines in commit.c:

  /* ### damn this is annoying to have to create a string */
  svn_string_t * propname = svn_string_create(SVN_RA_DAV__LP_ACTIVITY_URL,
                                              cc->ras->pool);

I needed to pass a constant property name to change_file_prop (it will be
set_wc_prop in the future), but the API required an svn_string_t. Bleck.

Re: Jim's comment on path handling: we have much of that in Apache right
now, and some stuff is already on the table for addition to APR. We can move
the rest into APR. IOW, yes: we'll have quite fine path handling for char*
style strings.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:23 2006

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.