Email list hosting service & mailing list manager

GC safety and return values Tom Lord (22 Dec 2003 20:58 UTC)
Re: GC safety and return values Jim Blandy (22 Dec 2003 21:26 UTC)
Re: GC safety and return values Tom Lord (22 Dec 2003 21:47 UTC)
Re: GC safety and return values tb@xxxxxx (22 Dec 2003 22:27 UTC)
Re: GC safety and return values Jim Blandy (22 Dec 2003 22:28 UTC)

Re: GC safety and return values Jim Blandy 22 Dec 2003 21:22 UTC

Tom Lord <xxxxxx@emf.net> writes:

> Some of the functions defined in the interface, for example:
>
>      scheme_value SCHEME_REAL_PART(scheme_value) (may GC)
>
> return a scheme_value as a C return value.
>
> This seems inherently error-prone.
>
> For example:
>
>     x = SCHEME_CONS (SCHEME_REAL_PART (a), SCHEME_REAL_PART (b));
>
> although a very natural seeming C statement, is incorrect code.  SCM
> makes that mistake (though its not a mistake within the goals of the
> SCM project itself), Guile inherited it (where it really is a
> mistake), and it proved to be a serious obstacle to, for example,
> implementing either precise or copying GC.
>
> For starters, I would like to see all return values passed via
> output parameters so that one would have to write:
>
> 	SCHEME_REAL_PART (&tmp1, a);
> 	SCHEME_REAL_PART (&tmp2, b);
>         SCHEME_CONS (&x, tmp1, tmp2);
>
> In fact I'd go beyond that in a few ways -- but let me just start with
> this and see where we get.

This is one area where having explicitly-freed reference objects, as
in the JNI, actually works better than the GC_PROTECT approach.  With
references, the first expression is perfectly fine --- assuming
SCHEME_REAL_PART always returns a local reference.