lynx-dev LYLowerCase EBCDIC Crash [PATCH]

[pg]

Hello, Lyncei,

The problem:  If the last character of a string has the 0x80 bit set,
the "i++" in LYLowerCase skips over the terminating NUL and LYLowerCase
coasts througm memory converting characters to lower case until it
encounters a NUL not preceded by 0x80.  This usually results in an
Invalid Heap at the next call to free() and Lynx crashes, leaving the
terminal in an insane state.

o This is an intense problem for EBCDIC -- ordinary EBCDIC characters
  (letters and digits have 0x80 set).  Clearly it's less a problem
  for ASCII, but is there a problem that a non-ASCII ISO8859 character
  might sneak into LYLowerCase and cause a crash?  I haven't checked
  all paths to LYLowerCase.

o The problem is manifest if environment variable LC_CTYPE=en_US at
  execution time; not if LC_CTYPE is unset at execution time,
  regardless that LC_CTYPE=en_US at configure and compile time in
  both cases.  I haven't tried to understand this.

o Is there a presumption that the setting of LC_CTYPE is identical
  at configure, compile, and execution time?  This isn't the cause
  of my problem -- it was en_US at all three points.  But if this is
  required it should be enforced with an error message.

o I simply disabled multibyte processing in LYLowerCase and LYUpperCase
  if EBCDIC is set.  This may be overkill.  But I've made no attempt
  to support multibyte EBCDIC processing elsewhere, so it's probably
  pervasively broken.  Perhaps someone else can suggest a more rational
  fix.  Should I perhaps disable SUPPORT_MULTIBYTE_EDIT early in some
  header file if EBCDIC is set?

o I notice that LYUpperCase ends with:

        buffer[i] = UCH(TOUPPER(buffer[i]));

  LYLowerCase ends with:

        buffer[i] = TOLOWER(buffer[i]);

  Is there some reason the UCH() conversion is present in LYUpperCase,
  but not needed in LYLowerCase?

Thanks,
gil
-- 
StorageTek
INFORMATION made POWERFUL

lynx.patch
Description: ascii text