I'd appreciate someone confirming that scm_c_eval_string doesn't leak
memory. From strports.c:
,----
| SCM
| scm_c_eval_string (const char *expr)
| {
| return scm_eval_string (scm_makfrom0str (expr));
| }
`----
(NB: This is from guile-1.6.7 - the CVS version has scm_makfrom0str
deprecated/discouraged.)
My concern is the cell returned from scm_makfrom0str, which would be
stack-resident as a temporary value. Scm_makfrom0str does a malloc to
allocate memory for expr, so if I was to do something like:
scm_c_eval_string("(display \"foo\")");
scm_c_eval_string("(display \"bar\")");
the stack frame created for the first call to scm_c_eval_string would be
overlaid on the second invocation, and the temporary cell created in the
first call overwritten so that the pointer from the first malloc is
lost and the memory allocated to hold "(display \"foo\")" leaked.
Am I needlessly worrying about this?
Additionally, within a Guile extension how can I handle cells returned
from library functions that are effectively thrown away? e.g.:
SCM_DEFINE( example, "example", 0, 0, 0, (), "Example." )
#define FUNC_NAME s_example
{
SCM tmp;
int n;
tmp = scm_c_eval_string("(list \"foo\" \"bar\" \"baz\")");
n = do_something_with_tmp(tmp);
return SCM_MAKINUM(n);
}
#undef FUNC_NAME
Will the list returned from scm_c_eval_string be garbage-collected, or
leaked?
thx -
--
Michael J. Barillier /// http://www.blackwolfinfosys.net/~blackwolf/
.O. | ``Experience with many protocols has shown that protocols with
..O | few options tend towards ubiquity, whereas protocols with many
OOO | options tend towards obscurity.'' -- RFC 2821
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
