You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Fuhrmann <eq...@web.de> on 2016/04/24 21:30:16 UTC

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


On 21.03.2016 17:08, Daniel Shahaf wrote:
> stefan2@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.