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

Re: [PATCH] Change error reporting for xlate problems

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Sun, 14 Jul 2013 02:06:02 -0400

On Sat, Jul 13, 2013 at 8:39 PM, Daniel Shahaf <danielsh_at_apache.org> wrote:

> It appears as soon as svn_utf_cstring_to_utf8() is called --- which is
> normally during argv parsing. The error happens even if the argv
> arguments are all ASCII, which effectively adds a new dependency on
> apr_xlate_* even for people who use only ASCII. I assume this new
> failure mode for ASCII-only users means we cannot backport this change.
>

This now means iconv or apr-iconv are a hard global dependency where they
haven't been before. I'm not sure that I like that. (If you're going to
do this patch, remove the if check for EINVAL/ENOTIMPL - it's unnecessary.)

IIRC, the reason is that this code gets called all the time - we had to
silence the ENOTIMPL and EINVAL errors as it really shouldn't be treated as
a fatal error. So, in this case, we're back to treating it as an
irrecoverable error.

It's probably better to just check APR_HAS_XLATE and return an error in
svnsync if that's 0...and let the string pass through unmodified - which is
probably fine for svnsync case...or perhaps go a step further and just
refuse to build svnsync if iconv isn't supported as we might not be able to
guarantee the integrity of the sync'd logs. I'm not sure how paranoid we
need to be here. -- justin
Received on 2013-07-14 08:06:44 CEST

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.