Re: OS/390 Translation

[pg...@sweng.stortek.com]

In a recent note, Greg Ames said:

> Date: Wed, 01 Dec 1999 17:01:19 -0500
> 
> >   +/* Use OS/390's built-in translation function to initialize tables.
> >   + */
> 
> I like the basic idea.  It's not as flexible as iconv() though, which we probably want to use eventually.
> 
I suspect they're pretty equivalent.  In fact, the RM states:

          The following are the possible values of errno: (This function  
   may internally call iconv_open() and iconv(). The errno's returned by
   these functions are propagated without modification.)

__atoe_l() has fewer arguments.  This makes it easier to use.  :-)
And it must set up a table, rather than calling iconv() (or __atoe_l())
when needed, because there are macros that access individual characters
in os_toebcdic[] directly.

> > +    os_toascii[012] = 012;
> > +    os_toascii[015] = 015;
> I think you mean:
>      os_toascii[\012] = \012;
>      os_toascii[\015] = \015;

I stand by my usage.  Does anyone want to vote on it?

> to pass thru the \012 and \015 EBCDIC constants contained in Apache unmolested to the ASCII world.
> 
> btw, is there a reason why we can't just use the symbolics CR and LF from httpd.h rather than \012 and \015 throughout Apache?  Seems like that would simplify things quite a bit  (\r and \n might
> cause trouble on MacOS and/or AS/400.)  A quick grep on my Linux box gives me 49 lines containing either \012 or \015.  Changing these to symbolics seems manageable if there's no gotchas.
> 
... but should these be \012 and \015 on an EBCDIC platform, or
\025 and \015?  In any case, these symbolics can't be incorporated
into constant strings.  And see Martin Kraemer's comment in
src/README.EBCDIC:

* This port therefore features a built-in protocol level conversion
  for the server-internal strings (which the compiler translated to
  EBCDIC strings) and server-generated documents. The hard coded
  ASCII escapes \012 and \015 which are ubiquitious in the server
  code are an exception: they are not converted to ASCII a second
  time.

It all seems very delicately balanced; I'm inclined to try not
to upset it.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL