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: [PATCH] Unicode Lisp reader escapes Date: Tue, 09 May 2006 22:05:07 +0300 Message-ID: References: <17491.34779.959316.484740@parhasard.net> <17495.932.70900.796282@parhasard.net> <17495.57895.90438.848865@parhasard.net> <17498.28361.392872.954484@parhasard.net> <17503.21672.395920.94783@parhasard.net> <17503.29740.778178.932671@parhasard.net> <17504.16146.57393.970540@parhasard.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1147202088 30939 80.91.229.2 (9 May 2006 19:14:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 9 May 2006 19:14:48 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 09 21:14:42 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FdXfL-0002V2-FU for ged-emacs-devel@m.gmane.org; Tue, 09 May 2006 21:14:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FdXfK-000190-Q5 for ged-emacs-devel@m.gmane.org; Tue, 09 May 2006 15:14:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FdXfA-00018i-7p for emacs-devel@gnu.org; Tue, 09 May 2006 15:14:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FdXf8-00017z-PO for emacs-devel@gnu.org; Tue, 09 May 2006 15:14:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FdXf8-00017q-JA for emacs-devel@gnu.org; Tue, 09 May 2006 15:14:26 -0400 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FdXgF-0006Zn-Mg for emacs-devel@gnu.org; Tue, 09 May 2006 15:15:35 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-156-30.inter.net.il [80.230.156.30]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id DHX06194 (AUTH halo1); Tue, 9 May 2006 22:05:04 +0300 (IDT) Original-To: Aidan Kehoe In-reply-to: <17504.16146.57393.970540@parhasard.net> (message from Aidan Kehoe on Tue, 9 May 2006 09:04:50 +0200) 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:54143 Archived-At: > From: Aidan Kehoe > Date: Tue, 9 May 2006 09:04:50 +0200 > Cc: emacs-devel@gnu.org > > > As far as I know, the GCPRO convention for arguments is mostly the > > following: > > > > GCPRO args you pass to functions iff those functions can GC and you need > > to use the arg after the function returns. > > Okay. Do you know of any document detailing that? Does the excerpt below from the Lisp manual answer your concerns? > No-one followed up to my reference to what Ben Wing writes on the > subject. AFAIU, he is wrong, or at least inaccurate. But maybe I misunderstand something. >>From (elisp)Writing Emacs Primitives: Within the function `For' itself, note the use of the macros `GCPRO1' and `UNGCPRO'. `GCPRO1' is used to "protect" a variable from garbage collection--to inform the garbage collector that it must look in that variable and regard its contents as an accessible object. This is necessary whenever you call `Feval' or anything that can directly or indirectly call `Feval'. At such a time, any Lisp object that you intend to refer to again must be protected somehow. `UNGCPRO' cancels the protection of the variables that are protected in the current function. It is necessary to do this explicitly. It suffices to ensure that at least one pointer to each object is GC-protected; as long as the object is not recycled, all pointers to it remain valid. So if you are sure that a local variable points to an object that will be preserved by some other pointer, that local variable does not need a `GCPRO'. (Formerly, strings were an exception to this rule; in older Emacs versions, every pointer to a string needed to be marked by GC.)