On Jan 13, 2005, at 12:54 PM, Philip Martin wrote:
> "Brian W. Fitzpatrick" <fitz@red-bean.com> writes:
>
>> On Wed, 2005-01-12 at 12:01, Philip Martin wrote:
>>> "Brian W. Fitzpatrick" <fitz@red-bean.com> writes:
>>>
>>>> I'll be coming through in a pass later today to turn most of the
>>>> apr_file_FOO calls into svn_io_file_FOO calls with a nice neat
>>>> SVN_ERR
>>>> wrapper around it (which should clean up the code a good bit).
>>>
>>> One difference between apr_ and svn_io_ is that the apr functions
>>> accept paths in the system's native encoding while the svn functions
>>> accept paths in UTF-8 and converts to native before calling apr.
>>> Now,
>>> the locking paths are ASCII representations of MD5 sums are they not?
>>> Does that mean that the encoding is irrelevant?
>>
>> Yes.
>
> I'm not convinced. There are at least two problems:
>
> 1. The restriction to ASCII only applies to the part of the path
> within the repository, the path to the repository may contain
> non-ASCII characters that require conversion.
>
> 2. Suppose I have LANG set to a UTF-16 encoding, then even the ASCII
> bits of the path will need to be converted.
>
> Thus, I think the current use of apr_ functions in lock.c is wrong.
> The paths need to undergo UTF-8 to native conversion before being
> passed to the apr_ functions, just as in the rest of Subversion. This
> applies to the apr_filepath_merge, apr_dir_make_recursive and
> apr_status calls.
You are, of course, completely correct.
This has been fixed in r12770.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 18 01:23:19 2005