Re: lynx-dev Lynx character entity references fix

[Leonid Pauzner]

9-Mar-99 12:45 Klaus Weide wrote:

> Among the previous changes (that are in dev.18/dev.19), the following
> looks wrong.  In UC_con_set_trans():

>     for (i = 0; i < UCInfo[UC_charset_in_hndl].num_n256; i++) {
>         if ((j = UCInfo[UC_charset_in_hndl].unicount[i])) {
>             ptrans[i] = *p;
>             for (; j; j--) {
>                 p++;
>             }
>         } else {
>             ptrans[i] = 0xfffd;
>         }
>     }

> Here ptrans points to one of the four tables (slots) in translations[].
> Your change leaves the table unchanged when it should be re-initialized.
> So (to-Unicode translation for) one charset could effectively inherit
> the translations for a completely different charset that used the same slot
> before.

> The closer equivalent to previous behavior would be to initialize all 256
> elements to 0xfffd.

You right - it should be checked at earlier stage.

Three functions use unicount[] - UC_con_set_trans(), UC_con_set_unimap()
and con_set_default_unimap(). The default table shouldn't be NULL, it's OK.
The first function is only called from UC_MapGN(), which in turn
called from UCTransChar* and protected by num_uni.
The second function is also called from UCTransChar* and protected by num_uni,
but either called from UCTransUniChar* where NOT protected by num_uni.
Not sure but num_uni=0 should probably protect both unicount[] and unitable[].
Well, in real life all those UCTrans* should not be called for CJK
nor x-transparent (not sure with utf-8).

Will undo my num_n256 hack and think a little more on it.

> It *seems* that *currently* this code will never be called for any of the
> charsets with num_n256==0 -- as long as they also have num_uni==0.
8> UC_con_set_trans() is only called from UC_MapGN(), and all calls to
> UC_MapGN() are "protected" by a preceding

>     if (!UCInfo[UChndl_in].num_uni)
>         return -11;


>    Klaus