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

Re: svn commit: r1735858 - /subversion/trunk/subversion/libsvn_subr/prefix_string.c

From: Stefan Fuhrmann <eqfox_at_web.de>
Date: Sun, 24 Apr 2016 21:30:16 +0200

On 21.03.2016 17:08, Daniel Shahaf wrote:
> stefan2_at_apache.org wrote on Sun, Mar 20, 2016 at 10:33:43 -0000:
>> Author: stefan2
>> Date: Sun Mar 20 10:33:43 2016
>> New Revision: 1735858
>>
>> URL: http://svn.apache.org/viewvc?rev=1735858&view=rev
>> Log:
>> * subversion/libsvn_subr/prefix_string.c
>> (svn_prefix_string__t,
>> svn_prefix_string__create): Extend docstrings and commentary.
>> No functional change.
>
> Thanks! One further suggestion:
>
>> @@ -207,14 +218,24 @@ svn_prefix_string__create(svn_prefix_tre
>> new_node = apr_pcalloc(tree->pool, sizeof(*new_node));
>> new_node->key = sub_node->key;
>> new_node->length = node->length + match;
>> - new_node->key.data[7] = '\xff';
>> + new_node->key.data[7] = '\xff'; /* This is not a leaf node. */
>
> Could you please document the magic number 0xFF? (It appears twice in
> the file)

Yup (it's nothing magic, just convenient).
See r1740732.

> Can the svn_prefix_tree__t API be used with NUL-terminated strings in
> any encoding? If only UTF-8 is permitted, that's fine, but the API
> documentation should state that. (I initially suspected 0xFF was used
> because it's part of no valid UTF-8 sequence.)

Any NUL-terminated strings are allowed but
0xff is still convenient because we mostly
use UTF8 strings.

-- Stefan^2.
Received on 2016-04-24 21:30:27 CEST

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.