On Mon, 22 Oct 2001 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
