Re: scm_remember

[Dirk Herrmann]

Hello everybody!

Have you taken a look at the scm_remember issue again?  I have the
following compromise suggestion:  We add the following functions

  /* If within a function you need to protect one or more scheme objects
   * from garbage collection, pass them as parameters to one of the
   * scm_remember_* functions below.  These functions don't do anything,
   * but since the compiler does not know that they are actually no-ops,
   * it will generate code that calls these functions with the given
   * parameters.  Therefore, you can be sure that the compiler will keep
   * those scheme values alive (on the stack or in a register) up to the
   * point where scm_remember_* is called.  In other words, place the call
   * to scm_remember_* _behind_ the last code in your function, that
   * depends on the scheme value to exist.
   *
   * Example:  We want to make sure, that the string object str does not
   * get garbage collected during the execution of 'some_function',
   * because otherwise the characters belonging to str would be freed and
   * 'some_function' might access freed memory.  To make sure that the
   * compiler keeps str alive on the stack or in a register such that it
   * is visible to the conservative gc we add the call to scm_remember_1
   * _after_ the call to 'some_function'.  Note that this would not be
   * necessary if str was used anyway after the call to 'some_function'.
   *   char *chars = SCM_STRING_CHARS (str);
   *   some_function (chars);
   *   scm_remember_1 (str);  // str will be alive up to this point.
   */
  void scm_remember_1 (SCM obj1);
  void scm_remember_2 (SCM obj1, SCM obj2);
  ...

and thus habe a uniform possibility to protect one or more objects
from garbage protection, plus we don't get conflicts with the current
definition of scm_remember.

However, I still recommend to deprecate scm_remember in its current form
because of the much more irritating implications with regard to object
protection.

Best regards
Dirk