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.
> From: Jim Blandy <jimb@xxxxxxxxxx>
>> For example:
>> x = SCHEME_CONS (SCHEME_REAL_PART (a), SCHEME_REAL_PART (b));
>>
>> although a very natural seeming C statement, is incorrect code. [....]
>> 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);
> 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.
I understand and appreciate your negative experience with GCPRO in
emacs; I even agree that an "explicitly-freed reference object"
approach evades that problem (assuming I infer correctly what you mean
by that); but....
I don't think there's anything seriously wrong with the GC_PROTECT
approach.
Anecodtally: After I forked guile to make systas I made a little
`lint' program -- it happened not to be for GC issues but for critical
section demarcations. It had to do flow analysis similar to what the
GC issues would take. It could output "right", "wrong" and "can't be
sure" for a given function. Worked like a charm and only took a
couple of weeks --- very simple-minded flow analysis was sufficient.
GCPRO needs additional tools -- and maybe some code cleanups in Emacs
(if it hadn't been abandoned) -- but it's not nearly as losing as
you've made it out to be in the past.
-t