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 Sperling <st...@elego.de> on 2009/03/05 00:55:14 UTC
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?
Stefan
> Modified:
> trunk/subversion/libsvn_subr/utf.c
>
> Modified: trunk/subversion/libsvn_subr/utf.c
> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_subr/utf.c?pathrev=36334&r1=36333&r2=36334
> ==============================================================================
> --- trunk/subversion/libsvn_subr/utf.c Wed Mar 4 14:57:55 2009 (r36333)
> +++ trunk/subversion/libsvn_subr/utf.c Wed Mar 4 15:43:55 2009 (r36334)
> @@ -716,6 +716,10 @@ svn_utf_cstring_to_utf8(const char **des
> const char *src,
> apr_pool_t *pool)
> {
> +#if defined(WIN32) || defined(DARWIN)
> + /* Apr internal charset is always UTF-8 */
> + *dest = apr_pstrdup(pool, src);
> +#else
> xlate_handle_node_t *node;
> svn_error_t *err;
>
> @@ -723,6 +727,7 @@ svn_utf_cstring_to_utf8(const char **des
> err = convert_cstring(dest, src, node, pool);
> put_xlate_handle_node(node, SVN_UTF_NTOU_XLATE_HANDLE, pool);
> SVN_ERR(err);
> +#endif
> return check_cstring_utf8(*dest, pool);
> }
>
> @@ -825,6 +830,11 @@ svn_utf_cstring_from_utf8(const char **d
> const char *src,
> apr_pool_t *pool)
> {
> +#if defined(WIN32) || defined(DARWIN)
> + /* Apr internal charset is always UTF-8 */
> + *dest = apr_pstrdup(pool, src);
> + return SVN_NO_ERROR;
> +#else
> xlate_handle_node_t *node;
> svn_error_t *err;
>
> @@ -835,6 +845,7 @@ svn_utf_cstring_from_utf8(const char **d
> put_xlate_handle_node(node, SVN_UTF_UTON_XLATE_HANDLE, pool);
>
> return err;
> +#endif
> }
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=1269194
Re: svn commit: r36334 - trunk/subversion/libsvn_subr
Posted by Branko Cibej <br...@xbc.nu>.
Greg Stein wrote:
> On Thu, Mar 5, 2009 at 11:19, Stefan Sperling <st...@elego.de> wrote:
>
>> On Thu, Mar 05, 2009 at 02:55:26AM +0100, Bert Huijben wrote:
>> ...
>>
>>>> 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 :)
>>
>
> Right. We could do the runtime check (once; stashed into a global)
> *unless* we see the #define. That gives us full compatibility, and
> will be even faster when the define finally appears.
>
I'm confused. I thought APR already had such #defines? At least for FS
encodings and for Windows; I'm pretty sure I added some myself, a long
time when.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1272726
Re: svn commit: r36334 - trunk/subversion/libsvn_subr
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Mar 5, 2009 at 11:19, Stefan Sperling <st...@elego.de> wrote:
> On Thu, Mar 05, 2009 at 02:55:26AM +0100, Bert Huijben wrote:
>...
>> > 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 :)
Right. We could do the runtime check (once; stashed into a global)
*unless* we see the #define. That gives us full compatibility, and
will be even faster when the define finally appears.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1272231
Re: svn commit: r36334 - trunk/subversion/libsvn_subr
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Mar 05, 2009 at 02:55:26AM +0100, Bert Huijben wrote:
> > -----Original Message-----
> > From: Stefan Sperling [mailto:stsp@elego.de]
> > Sent: Thursday, March 05, 2009 1:55 AM
> > To: dev@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
RE: svn commit: r36334 - trunk/subversion/libsvn_subr
Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: Thursday, March 05, 2009 1:55 AM
> To: dev@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