> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Sent: maandag 17 mei 2010 11:25
> To: Greg Ames
> Cc: Subversion Dev
> Subject: Re: [PATCH] readable error messages on non-ASCII systems, v2
> (Cc'ing the dev@ list.)
> On Fri, 2010-05-14, Greg Ames wrote:
> > Fri, May 14, 2010, Julian Foad wrote:
> > > In an attempt both to understand and to minimize the patch: would you
> > > get the same result by converting 'err->message' from native encoding to
> > > UTF-8 and then printing it in the way that it currently is printed?
> > I had to adjust the patch to fit 1.5.6 (no SQLite here). Then
> > svn_utf_* reported that there were non-UTF-8 characters at the
> > beginning of the message. This time it was the "svn: " prefix passed
> > to svn_cmdline_fprintf a few lines down. I changed the patch to also
> > convert the prefix input variable to UTF-8 and pass that to
> > svn_cmdline_fprintf, and I see readable error messages again.
> Hi Greg. Great - it sounds like that gives you a less invasive solution
> to that particular bit. Let us know how you get on.
Googling for z/OS and Ascii shows that there are some z/OS C compilers that allow compiling programs using ASCII literals.
(E.g. http://www-01.ibm.com/software/awdtools/czos/features/czosv1r2.html: See 'ASCII Support')
Did you try using these compiler flags instead of trying to fix the source code?
I'm afraid that you will only find more and more places where we assume that our literals use ASCII, so if I would have to fix Subversion I would look into using some automated tool. (Another thing I thought about was using some kind of C preprocessor before compiling, which translates the strings to utf-8 using some escaping mechanism)
I think our output handling is mostly separated to allow converting from utf-8 to the native encoding, so maybe applying a few compiler flags can help you more than patching the sourcecode.
> - Julian
Received on 2010-05-17 16:41:48 CEST