Why do Fdefvar not protect its argument and temporaries with GCPRO?

Why do Fdefvar not protect its argument and temporaries with GCPRO?

[Lee Duhem]

Hi all,

In the definition of `Fdefvar`, it calls `eval_sub`, and its temporary
variable `tail` is used after that call. So why do `Fdefvar` not protect
`tail` and other temporaries from GC with GCPRO? As other functions in
`src/eval.c` did.

Is this a bug? Or did I overlook something?

Sincerely,
lee

Re: Why do Fdefvar not protect its argument and temporaries with GCPRO?

[Andreas Schwab]

Lee Duhem <lee.duhem@gmail.com> writes:

> In the definition of `Fdefvar`, it calls `eval_sub`, and its temporary
> variable `tail` is used after that call. So why do `Fdefvar` not protect
> `tail` and other temporaries from GC with GCPRO? As other functions in
> `src/eval.c` did.

I think a few of them do too much GCPRO, since arguments of lisp
functions are protected by the caller (and conses are not relocated).
In the initial version of Fdefvar no intermediate values were stored in
variables, instead they were recomputed by calling Fcdr/Fcar on the
function argument, which is ok protection-wise.

> Is this a bug?

In this case, I think it is.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Why do Fdefvar not protect its argument and temporaries with GCPRO?

[Stefan Monnier]

> I think a few of them do too much GCPRO, since arguments of lisp
> functions are protected by the caller (and conses are not relocated).

Maybe I'm misunderstanding what you're saying, but to clarify:
The calling convention we use does not require the caller to
gcprotect the arguments, instead it's the callee who should protect its
own arguments, if and when needed.

>> Is this a bug?
> In this case, I think it is.

Agreed.


        Stefan

Re: Why do Fdefvar not protect its argument and temporaries with GCPRO?

[Lee Duhem]

On Wed, Nov 19, 2014 at 5:51 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I think a few of them do too much GCPRO, since arguments of lisp
>> functions are protected by the caller (and conses are not relocated).
>
> Maybe I'm misunderstanding what you're saying, but to clarify:
> The calling convention we use does not require the caller to
> gcprotect the arguments, instead it's the callee who should protect its
> own arguments, if and when needed.

Thank both of you for your explanation.

>
>>> Is this a bug?
>> In this case, I think it is.
>
> Agreed.
>

I have send a patch for this.

Sincerely,
lee