On Thu, Mar 05, 2009 at 02:55:26AM +0100, Bert Huijben wrote:
> > -----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.
What's the overhead involved in using the run-time check
instead of a #define?
> (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).
So the sooner we ask them to add a #define, the better :)
Stefan
Received on 2009-03-05 11:20:10 CET