"Erik Huelsmann" <e.huelsmann@gmx.net> wrote on 05/06/2004 06:34:28 PM:
> > Peter N. Lundblad wrote:
> > > ...
> > > Yes, that's what I'm going to do. Problem is this:
> > > - svn_cmdline_printf() takes UTF-8 *strings* and other argument
types
> > > - apr_psprintf will not touch the encoding of the strings, but it
will
> > > ocnvert %d etc. to the locale's encoding (no, it won't, it converts
it
> > > using numbers, . etc. from the C execution character set...)
> > > - When we are going to convert from UTF-8, we may have a mixed
encoing
> > > string:-(
> > >
> > > Since the digits and the other characters that apr_psprintf will
produce
> > > are in the ASCII (7-bit) range, they are the same for UTF-8 in
> > ASCII-based
> > > encodings. So this shouldn't be a problem in most cases. But what
> > happens
> > > on, i.e. EBCDIC systems? Anyone who knows?
> >
> > If you use stdio s(n)printf, the local encoding system is used.
> > Current EBCDIC-based systems (i.e. AS/400), to my knowledge, provide
> > a compile-time option for using EBCDIC or ASCII as the base
> > character set. If you compile in EBCDIC mode, then the numbers
> > will be in EBCDIC. However, so will all other characters, so the
> > whole "UTF-8 is a subset of the standard charset" assumption is
> > out the window. Compile in ASCII mode and those problems go away,
> > so *if* you decide to support those systems, that is probably the
> > only feasible way.
>
> These problems are dealt with starting with Peters newest patch
submission,
> right? (At least that is my understanding) If so, does that mean we have
a
> direction to work with now, on does the matter need more discussion?
>
> > Frankly, I doubt if Subversion compiles on AS/400 or any other
> > EBCDIC platform, so this is likely a non-issue.
> >
> >
> > At some point you may want to define a minimum platform to
> > support which includes being based on ASCII and not EBCDIC.
>
I hadn't been following this thread too closely, then suddenly noticed the
AS/400 reference. I am actively working on porting this to run on AS/400.
Since OS/400 includes Apache 2 as its built in HTTP server, I was/am
optimistic.
I was able to compile all of the Subversion code, although I am mainly
concentrating on the server aspects of this. I have not attempted Neon
yet. I have not been able to run/test it yet because I cannot currently
link the code. IBM provides APR with OS/400 and I discovered that they
were not exporting all of the APR functions in the libraries they provide.
There were about 10 missing total. I contacted IBM and they are going to
issue a fix for me, so I am idling until then. It isn't possible, or at
least not easy, to compile my own APR as the OS/400 patches were not
submitted back to Apache, so I have to rely on IBM. Then tend to keep up
with the HTTP releases pretty closely, so I have my fingers crossed that
these issues with APR were worked out.
While it is true that OS/400 is EBCDIC by default, it does have
ASCII/Unicode support as well. For example, when using Apache HTTP the
HTML pages it serves are still ASCII as is the configuration file.
Although interestingly, I think its log gets written in EBCDIC (I should
take a closer look at this). Generally speaking, OS/400 usually does the
EBCDIC/ASCII conversions automatically under the covers. So if I am
running an OS/400 program and I read an ASCII file, OS/400 will convert it
to EBCDIC inside the program, and if I write back out it will be ASCII
again. It is possible that is not the case when using C. The "more
native" OS/400 languages (RPG and COBOL) can probably make those
assumptions, where C will not.
Anyway, I was hoping/planning to use Subversion in full ASCII mode if
possible. I, and I think most AS/400 users, would want to run Subversion
as a server on their AS/400 for storing their Java/Web code which would be
developed on a PC. "Native" OS/400 development is just too different for
tools like Subversion to be helpful and there are plenty of native OS/400
products (including the one my company makes) that provide that. EBCDIC
would definitely be needed to support that kind of development.
Mark
Received on Fri May 7 02:58:25 2004