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

Re: svn commit: r34304 - trunk/subversion/svn

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 21 Nov 2008 14:54:10 +0000

On Fri, Nov 21, 2008 at 06:36:22AM -0800, Greg Stein wrote:
> On Fri, Nov 21, 2008 at 06:33, <stsp_at_tigris.org> wrote:
> >...
> > +++ trunk/subversion/svn/tree-conflicts.h Fri Nov 21 06:33:02 2008 (r34304)
> > @@ -35,14 +35,16 @@ extern "C" {
> >
> >
> > /**
> > - * Append to @a descriptions a possibly localized human readable
> > + * Return in @a desc a possibly localized human readable
> > * description of a tree conflict described by @a conflict.
> > *
> > + * Allocate the result in @a pool.
> > + *
> > * @since New in 1.6.
> > */
> > svn_error_t *
> > -svn_cl__append_human_readable_tree_conflict_description(
> > - svn_stringbuf_t *descriptions,
> > +svn_cl__get_human_readable_tree_conflict_description(
> > + svn_string_t **desc,
> > const svn_wc_conflict_description_t *conflict,
> > apr_pool_t *pool);
>
> Does this need to be an svn_string_t ? Couldn't it be a simple const char * ?

There seems to no API for creating C strings from a format string.
So since we have to create a svn_string_t anyway, why not pass it up?
I don't see much point in passing around naked pointers to C strings
wherever possible. Why have svn_string_t in the first place if we just
use it to create naked C strings from a format string (i.e. create
a svn_string_t s, but then return s->data)?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-21 15:54:27 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.