From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Aidan Kehoe Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Unicode Lisp reader escapes Date: Mon, 8 May 2006 08:54:22 +0200 Message-ID: <17502.60190.991262.681291@parhasard.net> 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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1147071285 21060 80.91.229.2 (8 May 2006 06:54:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 May 2006 06:54:45 +0000 (UTC) Cc: schwab@suse.de, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 08 08:54: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 1Fczdg-000800-SU for ged-emacs-devel@m.gmane.org; Mon, 08 May 2006 08:54:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fczdg-0005JM-Fr for ged-emacs-devel@m.gmane.org; Mon, 08 May 2006 02:54:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FczdT-0005Hd-A6 for emacs-devel@gnu.org; Mon, 08 May 2006 02:54:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FczdR-0005Fa-KU for emacs-devel@gnu.org; Mon, 08 May 2006 02:54:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FczdR-0005FO-E2 for emacs-devel@gnu.org; Mon, 08 May 2006 02:54:25 -0400 Original-Received: from [66.111.49.30] (helo=icarus.asclepian.ie) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FczeD-0000B3-Fq for emacs-devel@gnu.org; Mon, 08 May 2006 02:55:13 -0400 Original-Received: by icarus.asclepian.ie (Postfix, from userid 1003) id 273528008D; Mon, 8 May 2006 07:54:23 +0100 (IST) Original-To: Kenichi Handa In-Reply-To: X-Mailer: VM 7.17 under 21.5 (beta25) "eggplant" (+CVS-20060325) XEmacs Lucid X-Echelon-distraction: ISFR CNCIS ISACA snuffle ISSAA Shayet-13 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:54061 Archived-At: Ar an t-ocht=FA l=E1 de m=ED Bealtaine, scr=EDobh Kenichi Handa:=20 > >> > readcharfun is declared as a Lisp_Object in read1, so it should b= e > >> > possible to check it's type and only GCPRO when necessary. > >>=20 > >> I don't see any need to GCPRO readcharfun. When called from Lisp th= e > >> arguments are already protected by being part of the call frame, an= d > >> all uses from C protect the object by other means (eg, by being put= on > >> eval-buffer-list). >=20 > > That was my understanding of the code too.=20 >=20 > For instance, Fread is called from Fcall_interactively as > below: >=20 > Lisp_Object tem; > [...] > tem =3D Fread_from_minibuffer (build_string (callint_message), > Qnil, Qnil, Qnil, Qnil, Qnil, > Qnil, Qnil); > if (! STRINGP (tem) || SCHARS (tem) =3D=3D 0) > args[i] =3D Qnil; > else > args[i] =3D Fread (tem); >=20 > In the calling sequence of Fread->read_internal_start->read0->read1, I > see no place where the original `tem' is GCPROed. Do I overlook > something? I believe not, it does need to be protected.=20 Also, my understanding of the above code is that build_string allocates memory for a Lisp string, that is not visible from Lisp, and that will no= t be GCPROed. So if garbage collection happens during Fread_from_minibuffer= , it may disappear. Ben Wing, in the XEmacs internals manual, says this:=20 12. Be careful of traps, like calling `Fcons()' in the argument to anothe= r function. By the "caller protects" law, you should be `GCPRO'ing the newly-created cons, but you aren't. A certain number of functions that a= re commonly called on freshly created stuff (e.g. `nconc2()', `Fsignal()') break the "caller protects" law and go ahead and `GCPRO' their arguments = so as to simplify thngs, but make sure and check if it's OK whenever doing something like this.=20 This seems to me equivalent to calling Fcons in the argument to another function. Is GNU Emacs different in this? --=20 Aidan Kehoe, http://www.parhasard.net/