[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: EBCDIC

> -----Original Message-----
> From: jean-frederic clere [mailto:jfrederic.clere@fujitsu-siemens.com]

> I tried your way on a BS2000 and give up after finding that a lot
> of string
> fonction like ispace() were only for EBCDIC...

Yes, but it's easy to replace the <ctype.h> functions with an ASCII version.
It usually requires just a single 256-byte lookup table and a few macros.

> I convert the data in input/output and handle all strings in
> EBCDIC, I have got
> a run slapd but I have no time to finish it...
> I send as attachement the patch I needed to get the slapd running
> on my EBCDIC
> machine. (Just for Fun that some month old!)

The changes you sent are very minimal, I'm surprised it works. The unicode
library
will need more changes than you have here. Also by doing the translation
between
ASCII and EBCDIC in liblber you will corrupt any binary attributes that
happen to
be transmitted. This was a prime reason for taking my approach, as there is
no way
to guarantee the correctness of your results without access to schema info,
and the
schema info is not available to liblber. Also the code for UTF8 detection and
conversion assumes ASCII bytes, so all the tests for various bit patterns are
completely wrong for EBCDIC strings. Again, I'm surprised that you get any
usable
results at all, most of your DNs will be corrupted, if nothing else.

Finally, this means that all of your protocol traffic is incurring the
overhead
of a translation; your protocol performance will be slower than an
equivalently
fast machine running in native ASCII. With my approach, character translation
is
effectively done only for "offline" processing, and protocol traffic passes
thru
at full speed. So not only does it guarantee the correct protocol results,
but it
does so with optimal performance.
>
> I will try the new code on Monday on my machine and give some feedback.
>
> Cheers
>
> Jean-frederic
>
> >
> >   -- Howard Chu
> >   Chief Architect, Symas Corp.       Director, Highland Sun
> >   http://www.symas.com               http://highlandsun.com/hyc
> >   Symas: Premier OpenSource Development and Support
> >
> >
> >>-----Original Message-----
> >>From: Michael Stroder [mailto:michael@stroeder.com]
> >
> >
> >>Howard Chu wrote:
> >>
> >>>On the server side I'm considering what it would take to leave
> >>
> >>the internals
> >>
> >>>in UTF8 and just translate DNs specified in the config file. Could use
> >>>something
> >>>like BSD's xstr to extract the string constants from the source and
> >>>ASCII-encode
> >>>the ones that are ber_print'd as a preprocessing step. Still not
> >>
> >>sure, the
> >>
> >>>debug logs would be ugly.
> >>
> >>Make sure to find out which EBCDIC variant to use (see RFC1345).
> >>IMHO it's not worth the effort.
> >>
> >>Ciao, Michael.
> >
> >
> >
>
>
>

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support