Re: lynx-dev Autoconf patch for S/390 (EBCDIC)

[pg]

In a recent note, address@hidden said:

> Date: Fri, 30 Oct 1998 18:32:25 -0500 (EST)
> 
> Along that line - are your os390 patches stable enough for us to try
> absorbing some of it?  (It's simpler to keep in sync that way, and as
> I recall, the diffs aren't large).
> 
If you call a 2000 line context diff "not large", you may get it
from the URL in my previous posting.  Or, I'll E-mail it to you.
It needn't appear in these pages.

Yes, it would be easier to keep in sync that way, so I'd say at
present that "benign" is a better description than "stable".  I
regularly need to chase offsets and fuzzes applying patches.

I've tried to make my changes transparent to ASCII systems
in a few ways:

o I use symbolic instead of numeric constants in many places.
  I consider some of this merely good coding practice, such as:

      CH_ESC  instead of  27
          ' ' instead of  32 (or 040 or 0x20)
      CH_NBSP instead of 160
      CH_SHY  instead of 173

  with the names defined in a header file.  I couldn't do this
  uniformly -- at some points expanding numeric entities, the
  numeric use must remain.  And 160 is a particular nuisance:
  "ch == 160" is probably a test for CH_NBSP, while "ch >= 160"
  is probably a test for the high range of control characters,
  for which I defined a different symbol, CH_HICTL.

o Lynx has long had macros TOASCII(ch) and FROMASCII(ch) defined
  as identity functions.  I used "#ifdef NOT_ASCII" to make these
  do real work for the NOT_ASCII case.  I added numerous calls
  at points where these are needed but not used.  This should
  cause no change in the generated code in the ASCII case.  In
  a few cases I needed to rearrange code at the point of call to
  avoid repeated function calls in evaluation of macro arguments.

o In HTTCP.c I do a TOASCII translation before writing to the
  socket, and FROMASCII after reading from the socket.  Both
  these are in a "#ifdef NOT_ASCII" to avoid performance impact
  in the NOT_ASCII case.

Adding the TOASCII() and FROMASCII() calls and changing from
numeric to symbolic representation of character constants accounts
for most of the 2000 lines of changes.

Unicode entities, where pseudo-character values >256 occur
undoubtedly still have problems with EBCDIC.  I've not tested
this.  But I believe I've done nothing to break these on
ASCII platforms.

I've made no changes and done no testing of the nonstandard display
character set tables.

Enjoy,
gil