Re: lynx-dev stopping when viewing a site

[Klaus Weide]

On Wed, 18 Aug 1999, Leonid Pauzner wrote:

> That's very strange - you propose an equivalent changes:
> you replace
> > - static CONST struct unimapdesc_str dfont_replacedesc_fallback = 
> > {0,NULL,0,1};
> > !        NULL,NULL,0,dfont_replacedesc_fallback,\
> with
> > !        dfont_unicount,dfont_unitable,463,dfont_replacedesc,\
> 
> using one from def7_uni.h:
> ...
> static CONST struct unimapdesc_str dfont_replacedesc = {1944,repl_map,1,0};
> #define UC_CHARSET_SETUP UC_Charset_Setup("us-ascii",\
> "7 bit approximations (US-ASCII)",\
> dfont_unicount,dfont_unitable,463,\
> dfont_replacedesc,999,0,0)
> 
> But the last flag from {0,NULL,0,1} means "use fallback to def7_uni.h"
> according chartrans/readme.format, so you made an equivalent changes
> unless there is another bug somethere in UCDomap.c dealing with replace tables
> (I would surprized though since x-transparent charset DO fallback properly
> but I cannot test something CJK specific :)

It seems I found the relevant difference that was introduced by your
1999-03-04 reorganization.  The value uck returned by UCTransUniChar() is
-3.  That means UCTransUniCharStr() is not attempted, since that happens only
if -4 is returned (a normal "this character is not mapped" indication).  The
-3 is some other error condition.  It must come from this code in a call to
conv_uni_to_pc(code, 0):

        if (!hashtable_contents_valid)
            return -3;

The variable hashtable_contents_valid gets normally set to 1 (in
con_clear_unimap) when the first non-default output character set is
selected with UC_con_set_unimap(), and after that it never gets reset.
Don't ask me what *exactly* it's good for... but is is basically some
internal consistency check, to prevent looking up something in a table
before it has been initialized.

In our case, con_clear_unimap(0) has never been called.  The reason is
that your UC_CHARSET_SETUP_foo macros initialize UCInfo[..].unitable
to NULL.  UC_current_unitable is also initially NULL, so that comparisons
like the following (this one is from UCTransUniChar)

        ut = UCInfo[UChndl_out].unitable;
        if (ut != UC_current_unitable) {

yield a false result - NULL is compared to NULL.  So con_clear_unimap(0)
never gets called, and hashtable_contents_valid never gets initialized.

But this (and the hang that indirectly resulted from it) only happens 
if no other non-default, "normal" display character set has been used
(for actual lookup of a character) since the beginning of the session.
By first viewing some text (with non-ASCII characters) in some other
display character set (non-ASCII, non-CJK, non-transparent), and *then*
changing to a CJK d.c.s. and loading the problematic text, the hanging
may not happen!  (Somebody should confirm this.)  Not sure whether the
translation will be correct for all characters in that case.

With Henry's change this will not happen, since his 'unitable' pointers
are not NULL.  (OTOH with his change there are multiple character sets
that claim to be the default (with 'isdefault'); that doesn't look right.)
Before your changes around 1999-03-04, CJK character sets were not
present in UCInfo[] at all, and LYCharSet_UC[i].UChndl always had -1
for them, so that UCTransUniChar() would use the def7 default directly.

> So the problem assumed somethere else. Klaus was reporting a fix for
> LYUCFullyTranslate_1() - seems this is a source of the real problem in 
> subject.

That was the other half of the problem.  With that change alone, lynx
should not hang any more, but the remaining problem is also "real".
Some Latin 1 characters will appear untranslatable (and some fallback
will be used), but it depends on previous history.

PS. Please snip your quotes, don't append quoted patches all the time!

   Klaus