From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Unicode Lisp reader escapes Date: Wed, 10 May 2006 20:08:24 -0500 (CDT) Message-ID: <200605110108.k4B18ODO029227@jane.dms.auburn.edu> 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> <17505.33452.224807.946390@parhasard.net> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1147309795 20914 80.91.229.2 (11 May 2006 01:09:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 11 May 2006 01:09:55 +0000 (UTC) Cc: kehoea@parhasard.net, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 11 03:09:44 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 1FdzgW-0004EY-33 for ged-emacs-devel@m.gmane.org; Thu, 11 May 2006 03:09:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FdzgV-0003ac-8R for ged-emacs-devel@m.gmane.org; Wed, 10 May 2006 21:09:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FdzgH-0003aQ-Md for emacs-devel@gnu.org; Wed, 10 May 2006 21:09:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FdzgG-0003a6-1V for emacs-devel@gnu.org; Wed, 10 May 2006 21:09:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FdzgF-0003a3-RI for emacs-devel@gnu.org; Wed, 10 May 2006 21:09:27 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fdzhd-0006J6-9Z; Wed, 10 May 2006 21:10:53 -0400 Original-Received: from jane.dms.auburn.edu (jane.dms.auburn.edu [131.204.53.201]) by manatee.dms.auburn.edu (8.13.6/8.13.6) with ESMTP id k4B19PSj028349; Wed, 10 May 2006 20:09:25 -0500 (CDT) Original-Received: from jane.dms.auburn.edu (localhost [127.0.0.1]) by jane.dms.auburn.edu (8.13.4+Sun/8.13.4) with ESMTP id k4B18O46029230; Wed, 10 May 2006 20:08:24 -0500 (CDT) Original-Received: (from teirllm@localhost) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3/Submit) id k4B18ODO029227; Wed, 10 May 2006 20:08:24 -0500 (CDT) X-Authentication-Warning: jane.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: eliz@gnu.org In-reply-to: (message from Eli Zaretskii on Wed, 10 May 2006 20:49:41 +0300) 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:54211 Archived-At: Eli Zaretskii wrote: > It read ambiguously to me. ``Any Lisp object that you intend to refer to > again'' could be one that you intend to refer to in the bodies of the > functions you call. Can someone in the know (Richard?) state a clear rule? I think the ELisp manual should be unequivocal about the GCPRO issue. I probably responded to quickly to this and misunderstood the question. I am still not completely sure what the concrete question is, but maybe Richard will understand. In the meantime, after rereading the thread, there are some things that seem confusing to me and maybe my two questions imply your question. My questions concern two responses by Stefan to quotes from Aidan Kehoe: > Fread is intended to be called from Lisp (it¢s a subr). Functions called > from Lisp do not need to GCPRO their arguments, because the garbage > collector knows about the arguments, as it knows about all objects > allocated in Lisp. s/called/callable/ Are you sure we have such a convention? `(elisp)Writing Emacs Primitives' discusses writing primitives, gives For as an example, which carefully GCPROs its ARGS argument, then talks about how important GCPROing variables of type Lisp_Object is (if Feval is called and so on...) and then states that there is an exception: Lisp primitives that take a variable number of args at the Lisp level (other than special forms) do not need to GCPRO the args they are to receive at the Lisp level: that responsibility rests with their caller, because what is passed as an arg at the C level is a Lisp_Object * pointer to a C vector containing those Lisp args. To me, this leads to the "obvious" conclusion that Lisp primitives can safely forget about GCPROing their args iff (they take a variable number of args and are not special forms). Apparently Aidan Kehoe's assertion that Lisp primitives do not need to GCPRO their args is not fully accurate, because For does. Maybe that is because For is a special form, but if so, this is apparently nowhere pointed out in `(elisp)Writing'. On the other hand, my "obvious" conclusion from reading `(elisp)Writing Emacs Primitives' seems to be wrong too. Both Fdirectory_file_name and Fmake_directory_internal take a fixed number of args, one, `directory', and do not GCPRO it, even though they both call `call2' which calls Feval and they both still refer to their `directory' arg afterwards. > C code that calls functions intended to be called from Lisp is optimistic > at best if, without having checked, it relies on the assumption that that > the arguments to those functions will be GCPROed. 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. All C functions that call Fdirectory_file_name or Fmake_directory_internal still use `directory' after those latter functions return and they all GCPRO it. But what if a C function called Fdirectory_file_name or Fmake_directory_internal without using directory afterward? Would they need to GCPRO `directory'. To me, the logical answer would seem no, since it is the responsibility of the called function to protect its args. Do these two functions implicitly do that by the way the garbage collector is implemented or not? Sincerely, Luc.