[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Autoconf patch for S/390 (EBCDIC)
From: |
pg |
Subject: |
Re: lynx-dev Autoconf patch for S/390 (EBCDIC) |
Date: |
Sat, 31 Oct 1998 10:50:29 -0700 (MST) |
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