[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH]

From: Thomas E. Dickey
Subject: Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH]
Date: Mon, 22 Oct 2001 09:08:54 -0400 (EDT)

On Mon, 22 Oct 2001 address@hidden wrote:

> 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.

how do you determine the end of an EBCDIC string?

> 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.

If it isn't set, it should be POSIX C locale (I was up too late last
night, but seem to recall that's equivalent to US-ASCII).

> 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.

perhaps (in ncurses I had some things broken by LC_CTYPE - sorting files,
for instance), and overrode the locale to make things work during the

> 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?

probably a good idea

> 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?

probably the UCH was to fix a compiler warning, but is now redundant since
TOLOWER and TOUPPER use UCH() internally.

T.E.Dickey <address@hidden>

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]