[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
build).
> 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>
http://invisible-island.net
ftp://invisible-island.net
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
- lynx-dev LYLowerCase EBCDIC Crash [PATCH], pg, 2001/10/22
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH],
Thomas E. Dickey <=
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], pg, 2001/10/22
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], Thomas E. Dickey, 2001/10/22
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], pg, 2001/10/22
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], Thomas E. Dickey, 2001/10/22
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], pg, 2001/10/22
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], Thomas E. Dickey, 2001/10/22
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], pg, 2001/10/22
- Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], Thomas E. Dickey, 2001/10/22
Re: lynx-dev LYLowerCase EBCDIC Crash [PATCH], pg, 2001/10/22