From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs 22.2.90 pretest Date: Wed, 20 Aug 2008 19:07:02 +0300 Message-ID: References: <87y72ymcig.fsf@stupidchicken.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1219249176 12962 80.91.229.12 (20 Aug 2008 16:19:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Aug 2008 16:19:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 20 18:20:28 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KVqPj-0003rG-5J for ged-emacs-devel@m.gmane.org; Wed, 20 Aug 2008 18:20:03 +0200 Original-Received: from localhost ([127.0.0.1]:60739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVqOl-0002eN-QH for ged-emacs-devel@m.gmane.org; Wed, 20 Aug 2008 12:19:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVqDL-00012c-D9 for emacs-devel@gnu.org; Wed, 20 Aug 2008 12:07:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVqDJ-00010u-90 for emacs-devel@gnu.org; Wed, 20 Aug 2008 12:07:14 -0400 Original-Received: from [199.232.76.173] (port=48695 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVqDJ-00010k-4r for emacs-devel@gnu.org; Wed, 20 Aug 2008 12:07:13 -0400 Original-Received: from mtaout1.012.net.il ([84.95.2.1]:26870) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVqDI-00066b-H3 for emacs-devel@gnu.org; Wed, 20 Aug 2008 12:07:12 -0400 Original-Received: from HOME-C4E4A596F7 ([84.229.211.50]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K5W00EQJQ4JQO30@i-mtaout1.012.net.il> for emacs-devel@gnu.org; Wed, 20 Aug 2008 19:07:31 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102729 Archived-At: > Date: Wed, 20 Aug 2008 17:10:07 +0900 > From: YAMAMOTO Mitsuharu > > 2008-08-02 Eli Zaretskii > > * 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.