Re: Emacs 21.1 on HP-UX 10.20 behaves oddly

[Eli Zaretskii]

> Date: Mon, 21 Jan 2002 14:27:27 +0200 (EET)
> From: Esa A E Peuha <esa.peuha@helsinki.fi>
> 
> LC_CTYPE=fi_FI.iso88591
> default-enable-multibyte-characters t
> locale-coding-system iso-latin-1

Thanks.

> (gdb) xbacktrace
> Argument to arithmetic operation not a number or boolean.
> 
> I suppose this is because Emacs is not yet executing Lisp code at that
> point.

Probably.

> (gdb) backtrace
> #0  Fsignal (error_symbol=269674764, data=1345766972) at eval.c:1375
> #1  0x18ca20 in args_out_of_range (a1=1075650560, a2=268421032)
>     at data.c:137
> #2  0x191b10 in Faref (array=1075650560, idx=268421032) at data.c:1778
> #3  0x75ff4 in translate_char (table=1075650560, c=-14424, charset=-1,
>     c1=40, c2=3) at charset.c:376
> #4  0x82c64 in $0000016D () at coding.c:2024
> #5  0x8cfcc in decode_coding (coding=0x7b03ba10, source=0x403809a4
>     "\e(B2002-01-18", destination=0x40378c08
>     "\e(B/h/6/matl/peuha/.emacs.d/auto-save-listterm.el", src_bytes=13,
>     dst_bytes=295) at coding.c:4710
> #6  0x91b40 in decode_coding_string (str=807997220, coding=0x7b03ba10,
>     nocopy=1) at coding.c:5908
> #7  0x94200 in code_convert_string_norecord (string=807997220,
>     coding_system=270307572, encodep=0) at coding.c:6586
> #8  0x19cfa0 in Fformat_time_string (format_string=807997236,
>     time=1342356960, universal=269552644) at editfns.c:1544
> 
> #3 shows that translate_char is called with bogus arguments; #4 points
> to a invocation of macro DECODE_ISO_CHARACTER in decode_coding_iso2022,
> but DECODE_ISO_CHARACTER is defined to call translate_char with c=-1,
> not -14424.  So, it appears that the file coding.c is miscompiled by the
> native cc of HP-UX.

I'm not sure your analysis is correct.  DECODE_ISO_CHARACTER indeed
calls translate_char with c=-1, but translate_char has this code at
its beginning:

    int
    translate_char (table, c, charset, c1, c2)
         Lisp_Object table;
         int c, charset, c1, c2;
    {
      Lisp_Object ch;
      int alt_charset, alt_c1, alt_c2, dimension;

      if (c < 0) c = MAKE_CHAR (charset, (c1 & 0x7F) , (c2 & 0x7F));
      if (!CHAR_TABLE_P (table)
          || (ch = Faref (table, make_number (c)), !NATNUMP (ch)))
        return c;

So when c is negative, its value is computed as

  MAKE_CHAR (charset, (c1 & 0x7F) , (c2 & 0x7F))

It's possible that GDB shows the actual value of c at the moment of
crash, not the value passed to translate_char when it was called.

So could you please step with GDB through the beginning of
translate_char, during the specific call which eventually causes
Fsignal to be invoked, and see whether c is -1 initially?

If this is indeed so, the next step is to see what kind of object is
in idx inside Faref.  (I suspect some snafu with signed/unsigned, so
please see whether the result of MAKE_CHAR above gets munged on its
way through make_number and into Faref.)

Also, I'm not sure that charset being -1 is okay, so please see what
does MAKE_CHAR does in that case.

Finally, I wonder where does the string "\e(B2002-01-18", the one
Emacs tries to decode, comes from?  It looks like it's 2002-01-18
with an ISO-2022 leading escape sequence, but why would Emacs try to
do something with that string during startup?  Could you try to find
that out?

TIA