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