more on GC issues

[Tom Lord <lord@xxxxxxx>]

I mentioned earlier that return values should really be via 
return parameters.

Argument parameters should be via references (pointers) as well:
otherwise, people can just recreate the same problem:



	scheme_value
        my_helper_fn (scheme_value * a)
        {
          scheme_value a_copy;

          a_copy = *a;

          a = SCHEME_NULL;
          return a_copy;
        }


and later:

        /* GC-unsafe code:

	x = SCHEME_CAR (my_helper_fn (&some_var));


With the changes I'm suggesting, one couldn't write my_helper_fn at
all and would have to write calls like:


	SCHEME_CAR (&x, &some_var);


Also, direct assignment to protected local variables should be
forbidden.   An incremental GC, for example, might want a write
barrier there.   So, not:

	scheme_value x;
	scheme_value y;

        [...]

        x = y;


but

	SCHEME_LSET (&x, &y)

As a matter of convenience, I think that GCPROing individual variables
is a bother.   I prefer an interface like:


	{
          struct foo_frame
          {
            SCHEME_VALUE_FRAME;

            scheme_value x;
            scheme_value y;
          } l;

          SCHEME_PROTECT_FRAME (l);

          [....]

          SCHEME_CAR (&l.x, &l.y);
          SCHEME_LSET (&l.y, &l.x);

          [...]

          SCHEME_UNPROTECT_FRAME (l);

         }

Also, SRFI-50 doesn't discuss the interaction of GCPROing a variable
with initializing, but it needs to.


-t