----- Original Message -----
> On Sat, Jul 23, 2011 at 01:36:07PM -0000, Igor Galić wrote:
> > > On OpenBSD I have to apply this patch to GNU iconv to avoid
> > > a similar problem in Subversion's prop_test 22 (with apr-util
> > > 1.3.12).
> > > But I don't recall the details.
> > >
> > > --- lib/aliases.gperf.orig Wed Oct 24 23:41:32 2007
> > > +++ lib/aliases.gperf Wed Oct 24 23:47:38 2007
> > > @@ -10,6 +10,7 @@ struct alias { int name; unsigned int
> > > encoding_index;
> > > %pic
> > > %%
> > > US-ASCII, ei_ascii
> > > +646, ei_ascii
> > > ASCII, ei_ascii
> > > ISO646-US, ei_ascii
> > > ISO_646.IRV:1991, ei_ascii
> >
> > I have *no* idea what that does.
>
> It makes GNU iconv recognise "646" as an alternative name for the
> "ASCII" encoding.
>
> > I applied it to the ports anyway,
> > recompiled/reinstalled the port and recompiled subversion to get
> > the exact same failure as before.
>
> Hmmm. I guess you'll have to dig down into the problem with a
> debugger.
> Can you find out which function is failing, and why?
> Basically, break at subversion/libsvn_subr/utf.c:check_non_ascii(),
> and look at the backtrace to figure out which call to
> get_ntou_xlate_handle_node() (in the same file) is failing.
> Then you'll have to drill down from there, maybe into iconv itself,
> and figure out why you're getting an error.
> This is nasty because there are many layers involved (svn uses apr
> uses iconv), but once you know where the error really comes from we
> should be able to fix this.
It seems to consistently fail when converting from ISO-8859-1
to UTF-8, same in utf-test, where it fails to translate from
"Edelwei\xdf" to "Edelwei\xc3\x9f"
Now I just have to find out why.
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
