Re: Emacs 22.2.90 pretest

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 20 Aug 2008 19:07:02 +0300, Eli Zaretskii <address@hidden> said:

>> 2008-08-02 Eli Zaretskii <address@hidden>
>> 
>> * fileio.c (Fexpand_file_name): Convert the value of $HOME to a
>> multibyte string.
>> 
>> The above change contains the same problem I pointed out in
>> http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-03/msg00026.html.
>> I.e., DECODE_FILE may GC, and pointers to Lisp String contents are
>> not valid after that because of relocations by compaction.

> Please suggest which variables to GCPRO.

GCPRO doesn't help here.  It just protects Lisp Objects from being
collected, but not for Lisp String contents from being relocated.
Anyway GCPRO is nowadays NOOP on most platforms because of
conservative GC.

> The code is convoluted, but I did try to walk through it and see if
> any variables need to be protected from GC.  Most of the code that
> uses nm[] (the only variable you mentioned back in March) is on
> DOS_NT, where the original string is copied to a stack-allocated
> buffer right at the beginning, and manipulated there; the original
> pointer to a Lisp_Object is forgotten, so GC cannot possibly cause
> harm on those platforms.

Yes, `nm' is not corrupted if DOS_NT because of copying.  But
otherwise, it may be corrupted by GC and it is actually used
afterwards.

  1455    if (1
  1456  #ifndef DOS_NT
  1457        /* /... alone is not absolute on DOS and Windows. */
  1458        && !IS_DIRECTORY_SEP (nm[0])
  1459  #endif

> Perhaps I missed something, but in that case please make specific
> suggestions which variables to protect and why, because the general
> principle that GC can move strings is obviously not news to me.

You can find some follow-up changes by others in the trunk to address
this issue, but with some `FIXME' comment.  I'm not sure if it is good
to apply such changes to the EMACS_22_BASE branch as that comment may
imply they are somewhat experimental.

                                     YAMAMOTO Mitsuharu
                                address@hidden