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

Re: svn commit: r1503010 - /subversion/trunk/subversion/libsvn_subr/utf.c

From: Daniel Shahaf <danielsh_at_apache.org>
Date: Mon, 15 Jul 2013 15:36:40 +0300

Philip Martin wrote on Mon, Jul 15, 2013 at 11:22:27 +0100:
> danielsh_at_apache.org writes:
>
> > Author: danielsh
> > Date: Sun Jul 14 18:07:54 2013
> > New Revision: 1503010
> >
> > URL: http://svn.apache.org/r1503010
> > Log:
> > svn_utf_*: Improve error handling.
> >
> > This is part of a patch I posted recently. The remaining part --- handling
> > APR_EINVAL and APR_ENOTIMPL as fatal errors --- may be committed separately
> > (for ease of backporting).
> >
> > * subversion/libsvn_subr/utf.c
> > (xlate_alloc_handle): Tweak the error handling so that apr_strerror() of the
> > error code is included in the error chain, in addition to the custom error
> > added here. The incumbent code would report error codes such as E70023,
> > but mere mortals aren't supposed to know what errno error that maps to,
> > and that is useful information:
> >
> > svn: E070023: Can't create a character converter from native encoding to 'UTF-8'
> > svn: E070023: This function has not been implemented on this platform
>
> Is that an example of the old output, or the new output, or something
> else? E070023 is ENOTIMPL and xlate_alloc_handle catches that error and
> so will not produce any error output.

That is example of how the output looks in combination with the patch to
s/else if/if/. It's representative insofar as 70023 is APR_ENOTIMPL and
the last element of the error chain is apr_strerror(ENOTIMPL), but you
are correct that xlate_alloc_handle() can't produce it in HEAD.
Received on 2013-07-15 14:37:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.