forgot to cc: dev again.
---------- Forwarded message ----------
From: Greg Ames <ames.greg_at_gmail.com>
Date: Fri, May 21, 2010 at 10:28 AM
Subject: Re: [PATCH - v3] readable error messages on non-ASCII systems
To: Stefan Sperling <stsp_at_elego.de>
On Thu, May 20, 2010 at 7:23 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Thu, May 20, 2010 at 03:10:04PM -0400, Greg Ames wrote:
> > I see that the svn ctype functions are hardwired to ASCII. If they
> called
> > the equivalent apr ctype functions instead, they should become portable
> to
> > EBCDIC. Doing that should change the behavior of
> > svn_utf__cstring_from_utf8_fuzzy() and produce readable normal messages
> as
> > well as the error messages.
>
> Have you tried tweaking svn_ctype.h to use the ctype functions from APR?
> Does that fix your problem?
>
I tried, but no luck the first time, so I just quickly re-tweaked it to use
the native OS ctypes. That worked great! Most of the messages are readable
now. It's a rather convoluted code path but I can't knock success.
Looking back at APR's include/apr_lib.h, I see the problem:
/** @see isascii */
#ifdef isascii
#define apr_isascii(c) (isascii(((unsigned char)(c))))
#else
#define apr_isascii(c) (((c) & ~0x7f)==0)
#endif
I don't see anything that #defines isascii, so I fell into the #else which
is ASCII bit pattern dependent too. I'll just tweak the #ifdef and it
should work fine for me. The other APR ctypes are fine.
.
> If it helps we could either discard the custom ctype implementation
> (I don't really see a need for svn to have its own ctype implementation),
> or at least use the apr versions #ifdef'd for your platform.
>
I would think that APR should be its home eventually. I'll submit an
#ifdef'd patch after I take care of / test APR.
>
> Have you looked at the old ebcdic branch?
> http://svn.apache.org/viewvc/subversion/branches/ebcdic/?r=876004
> You might want to try to get a diff of the work done on that branch
> relative to its origin, to see what people did back then to make
> Subversion deal with ebcdic.
>
Yes I did look at it. That should be a big help.
But although cheap branches are a very cool feature, I don't think huge code
drops in branches, patches, or otherwise are a good way to get code changes
into trunk in an open source project. IMO you get more eyballs and better
reviews if you can decompose it into small patches.
Greg
Received on 2010-05-21 17:05:19 CEST