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.
>
>
I agree with Philip. It's dangerous to make any kind of assumption about
path encoding, or to take shortcuts.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 14 13:13:16 2005