Julian Foad <julianfoad@btopenworld.com> wrote on 02/10/2005 06:42:16 PM:
> Mark Phippard wrote:
> > In writing a reply to Julian about our use of escape characters in our
> > EBCDIC port, it seemed like a good time to offer up a more detailed
> > explanation of what we are doing and where we are.
>
> Thanks. This will be very interesting.
>
> > You can download our current patch against the 1.1.x branch here:
> >
> > http://support.softlanding.com/ebcdic.diff
>
> While looking at your patch, I couldn't help reviewing it a bit...
Hi Julian, thanks for taking a quick look at the patch, appreciate the
comments.
> > Index: libsvn_subr/io.c
> > ===================================================================
> [...]
> > @@ -1968,7 +2088,8 @@
> > return SVN_NO_ERROR;
> >
> > err = file_name_get (&name, file, pool);
> > - name = (! err && name) ? apr_psprintf (pool, "file '%s'", name)
> : "stream";
> > + name = (! err && name) ? apr_psprintf (pool, FILE_STR
SVN_UTF8_SPACE_STR
> > + "\x27%s\x27", name) :
STREAM_STR;
> > svn_error_clear (err);
> >
> > return svn_error_wrap_apr (status, "Can't %s %s", op, name);
>
> Here you are passing a native format-string ("Can't %s %s") but
UTF8arguments
> ("name", at least) to svn_error_wrap_apr.
The explanation that we wrote up and Mark recently posted is somewhat of a
simplification. Our intent was to give a high level view of the problems
we face and our current solutions. So I left out some of the details...or
less charitably, I forget about them :)
When creating the patch we accidentally left out two new files, which are
essential to this tale of ebcdic induced woe:
/subversion/include/svn_ebcdic.h
/subversion/libsvn_subr/svn_ebcdic.c
This is a temporary "holding pen" for functions we use to solve
ebcdic/iSeries related issues, but are unsure about where in the
subversion code base they ultimately belong or if we will even need them
in the end. One of these functions is:
char *svn_ebcdic_pvsprintf (apr_pool_t *p, const char *fmt, va_list ap)
This works like apr_pvsprintf except that it assumes and %c or %s variable
args are utf-8 encoded and converts them to ebcdic when building the
return string. svn_error_createf and svn_error_wrap_apr both call
svn_ebcdic_pvsprintf rather than apr_pvsprintf if APR_CHARSET_EBCDIC is
true.
Given our assumption "C" (that all strings/chars in the non-mod_dav_svn
subversion code are utf-8) the numerous calls to svn_error_createf and
svn_error_wrap_apr pass utf-8 char/string var args. In an exception to
our assumption C though, we leave the format strings as ebcdic, as they
need to eventually be native for APR to use. The above approach saved us
having to convert every string or char var arg to ebcdic prior to
creating/wrapping errors - which would make for a much larger patch. This
reveals our "secret" assumption G) Don't muck up the code with endless
APR_CHARSET_EBCDIC dependent conversions if there is a way around it!
> I haven't reviewed carefully. I just noticed these while flicking
through it.
>
> - Julian
Mark mentioned earlier that our biggest challenge is getting IBM
Apache/MOD_DAV to work correctly with MOD_DAV_SVN. As a result we tried
to solve the "simpler" issues and move along quickly to the mod_dav_svn
crux, leaving some of the early work in a less than polished state. I
mention this for the benefit of anyone who does do a thorough review on
the current patch, we are aware it's not quite ready for prime time and
will inspect and clean it up prior to any commit to the proposed ebcdic
branch.
Thanks again,
Paul B.
SoftLanding Systems, Inc.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 11 16:52:36 2005