Fwd: [PATCH] use APR's ctypes on EBCDIC systems

forgot to cc: dev

On Mon, May 24, 2010 at 8:13 PM, Branko Čibej <brane_at_xbc.nu> wrote:

>
> >
> > Others have ported Subversion to EBCDIC systems
> >
> >
> > It was OS/400 (aka. iSeries). OS/390 was an earlier brand name for z/OS.
>
> (ISTR now that you had something to do with thosat port, right?)
>

I contributed a bunch to the httpd 2.x port to z/OS and to the MPMs, and to
APR on z/OS to a lesser extent. I haven't worked on OS/400. I suspect that
it has more complete runtime library support for ASCII than the z/OS
LIBASCII does.

> printf style format strings and args for other (but not all) library
> functions are expected to have native encoding on z/OS, so using the
> #pragmas is not as easy as I would like.

 Oh ouch. That's going to make things realy evil. Imagine, our
> translations are coded in UTF-8 and quite a few printf-style format
> strings come from there.

$ find . -name .svn -prune -o -print | xargs grep "_(.*%"
[...]
./subversion/svnserve/main.c: _("svnserve: Root path '%s'
does not exist "
./subversion/svnserve/serve.c: _("Unknown
revprop word '%s' in log command"),
[...]
$ find . -name .svn -prune -o -print | xargs grep "_(.*%" | wc -l
1072
$

yeah it will be challenging. I did notice that the _() macro could pick up
either literal strings or real UTF-8 depending on ENABLE_NLS.

However ... if I'm not too much mistaken, we
> use APR's formatter functions almost everywhere -- I believe the notable
> exception are the command-line output functions.

that's where I first noticed problems.

Are you sure you can't just tickle those, makeing them (elegantly)
> z/OS-specific?

it is amazing how much better the output looks by deleting one charset
conversion from the command line fputs function. that's not a final
solution, but it suggests that it shouldn't be too bad.

> For example, we do some special magic just for the console output on
> Windows.
>

thanks, I'll see if I can find the magic.

Greg
Received on 2010-06-02 23:43:59 CEST