Re: Emacs 23.1.93 pretest

[Eli Zaretskii]

> From: Chong Yidong <address@hidden>
> Cc: address@hidden
> Date: Tue, 02 Mar 2010 14:53:51 -0500
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > Actually, it turns out it's not ``reshuffling the heap'' that triggers
> > the bug, but rather the fact that when we call xmalloc, Emacs might
> > relocate buffer text.
> >
> > IOW, I found the reason for the bug.  One of the callers of
> > load_charset_map_from_file maintains pointers into buffer text, so
> > when that gets relocated, ... you get the idea.
> 
> Could you point out where this happens?

Yes, I can, now that I know that myself ;-)

The problem was in two places: in emacs_mule_char and in
decode_coding_emacs_mule (which calls emacs_mule_char).
emacs_mule_char called DECODE_CHAR, which could result in a call to
decode_char, which could call load_charset_map_from_file (through
load_charset).  Both emacs_mule_char and decode_coding_emacs_mule walk
through buffer text with pointers, and those need to be fixed-up after
the call to load_charset_map_from_file.

I replaced the call to DECODE_CHAR with CODING_DECODE_CHAR, which
wraps DECODE_CHAR with code that fixes up the pointers to buffer text
if a charset map was loaded by DECODE_CHAR.  decode_coding_emacs_mule
needed a similar fixup for its own pointers to buffer text.

This is now fixed in the repository.  I think this fixes the original
problem; at least my .emacs.desktop file with a Latin-2 character now
loads correctly, both in the MS-Windows build and in the MS-DOS build.

Perhaps Handa-san could look at the two other callers of DECODE_CHAR
in coding.c, and see if they, too, need to be replaced with
CODING_DECODE_CHAR.