emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Unicode Lisp reader escapes


From: Luc Teirlinck
Subject: Re: [PATCH] Unicode Lisp reader escapes
Date: Wed, 10 May 2006 20:08:24 -0500 (CDT)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]