unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs 22.2.90 pretest
Date: Wed, 20 Aug 2008 19:07:02 +0300	[thread overview]
Message-ID: <uiqtv4qmx.fsf@gnu.org> (raw)
In-Reply-To: <wlk5ec150g.wl%mituharu@math.s.chiba-u.ac.jp>

> Date: Wed, 20 Aug 2008 17:10:07 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> 2008-08-02  Eli Zaretskii  <eliz@gnu.org>
> 
> 	* 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.

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.

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.




  parent reply	other threads:[~2008-08-20 16:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-15 17:08 Emacs 22.2.90 pretest Chong Yidong
2008-08-16  7:57 ` Eli Zaretskii
2008-08-16  8:20   ` Eli Zaretskii
2008-08-16  8:41   ` Eli Zaretskii
2008-08-16 13:43     ` Chong Yidong
2008-08-16 15:23       ` Agustin Martin
2008-08-16 16:53         ` Chong Yidong
2008-08-16 16:20       ` Eli Zaretskii
2008-08-16 13:47   ` Chong Yidong
2008-08-17  5:09   ` Jason Rumney
2008-08-17 18:44     ` Eli Zaretskii
2008-08-17 17:54 ` Lennart Borgman (gmail)
2008-08-20  8:10 ` YAMAMOTO Mitsuharu
2008-08-20 14:44   ` Chong Yidong
2008-08-25 18:54     ` Eli Zaretskii
2008-08-20 16:07   ` Eli Zaretskii [this message]
2008-08-21  0:51     ` YAMAMOTO Mitsuharu
2008-08-21  5:35       ` Eli Zaretskii
2008-08-21  6:16         ` YAMAMOTO Mitsuharu
2008-08-21 11:25           ` Kenichi Handa
2008-08-20  8:21 ` YAMAMOTO Mitsuharu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=uiqtv4qmx.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=mituharu@math.s.chiba-u.ac.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).