Email list hosting service & mailing list manager

more on GC issues Tom Lord 23 Dec 2003 23:27 UTC

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:

        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;


	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 x;
            scheme_value y;
          } l;



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




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