Re: svn commit: r1412418 - in /subversion/trunk/subversion: include/private/svn_string_private.h libsvn_subr/string.c

Branko Čibej wrote:

> On 22.11.2012 10:30, Bert Huijben wrote:
>>> URL: http://svn.apache.org/viewvc?rev=1412418&view=rev
>>> Log:
>>> Groundwork for issue #4261. Invent memory buffers.
>> Issue #4261 is called "Setting unknown svn: propnames should require
> 'force'", so I think you want to reference a different issue number
> here.
>
> Nope, this is exactly what I'm laying the groundwork for. As will become
> obvious in the next couple days.

It's kind to the reader if we include the issue's subject line when quoting an issue number out of context like this.  Of course, if all our systems automatically annotated and hyperlinked issue number references, that wouldn't be necessary.

> +/** A self-contained memory buffer of known size.
> + *
> + * Intended to be used where a single variable-sized buffer is needed
> + * within an iteration, a scratch pool is available and we want to
> + * avoid the cost of creating another pool just for the iteration.
> + */
> +typedef struct svn_membuf_t

What does that comment about scratch pools and iterpools mean?

I don't follow what characteristics this new memory buffer has, and how it compares with svn_stringbuf_t.  You realize svn_stringbuf_t already supports arbitrary data with null characters in it?

svn_stringbuf_t seems to be all of this, and more because it tracks the length of the user's data separately from the allocated length.  What are the advantages of this new buffer?

- Julian
Received on 2012-11-22 16:09:07 CET