bug#36740: 27.0.50; apparently buggy code in ccl.c (lookup-integer-constant)

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 20 Jul 2019 12:29:57 +0000
> 
> This code in ccl.c
> 
>         eop = hash_lookup (h, make_fixnum (reg[RRR]), NULL);
>         if (eop >= 0)
>           {
>             Lisp_Object opl;
>             opl = HASH_VALUE (h, eop);
>             if (! (IN_INT_RANGE (eop) && CHARACTERP (opl)))
>               CCL_INVALID_CMD;
>             reg[RRR] = charset_unicode;
>             reg[rrr] = eop;
>             reg[7] = 1; /* r7 true for success */
>           }
>         else
>           reg[7] = 0;
> 
> seems wrong to me. We look up the hash value for reg[RRR], but then we
> store the hash _index_ into reg[rrr], and throw away the actual value.

The comment for the op-code says:

  #define CCL_LookupIntConstTbl 0x13 /* Lookup multibyte character by
                                        integer key.  Afterwards R7 set
                                        to 1 if lookup succeeded.
                                        1:ExtendedCOMMNDRrrRRRXXXXXXXX
                                        2:ARGUMENT(Hash table ID) */

so there appears to be no significance to r7's value?

Why did you think this code was wrong?  And why is this important in
the context of your playing with hash tables?

> The bug appears to be present in:
> 
> commit d325055a00e658a38c1721fcc63ed1775dd8ccb3
> Author: Dave Love <fx@gnu.org>
> Date:   Tue Jul 30 11:31:54 2002 +0000
> 
> which added the code, so I'm not sure whether there's external code
> which might rely on the buggy behavior (unlikely, I think). Is there
> any code actually making use of this CCL feature?

I don't see ccl-compile-lookup-integer used anywhere, FWIW.
I've CC'ed Handa-san, who might have some comments about this.