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

Re: GC safety and return values

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.



Tom Lord <lord@xxxxxxx> 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.