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

RE: svn commit: r36334 - trunk/subversion/libsvn_subr

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Thu, 5 Mar 2009 02:55:26 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Thursday, March 05, 2009 1:55 AM
> To: dev_at_subversion.tigris.org
> Subject: Re: svn commit: r36334 - trunk/subversion/libsvn_subr
>
> On Wed, Mar 04, 2009 at 03:43:55PM -0800, Bert Huijben wrote:
> > Author: rhuijben
> > Date: Wed Mar 4 15:43:55 2009
> > New Revision: 36334
> >
> > Log:
> > * subversion/libsvn_subr/utf.c
> > (svn_utf_cstring_to_utf8, svn_utf_cstring_from_utf8):
> > On platforms where the apr internal character set is always UTF-
> 8,
> > just copy the data instead of attempting to convert it. On
> converting
> > to utf-8 keep the validation step for compatibility reasons.
> > (This optimization applies to Windows and Mac OS).
> >
> > On Windows this avoids initializing COM in our process for only
> > doing simple things like parsing the passed pathnames.
>
> Is there some platform-independent way to test for this?
> Something like APR_INTERNAL_CHARSET_IS_ALWAYS_UTF8?
> If such a mechanism is not yet provided by APR, shouldn't
> we ask them to add it?

There is only a runtime check to get the type supported in the current apr
versions. For a future apr version it would be nice if they provided an
#define, but for the foreseeable future we can't trust the macro to be
there.

(We currently support Apr 0.9.X-1.3.X and I don't think they are going to
backport such a feature request to these old versions).

        Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1269963
Received on 2009-03-05 02:56:51 CET

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.