Displaying 3 results from an estimated 3 matches for "cfunc2".
Did you mean:
cfunc
2014 Mar 06
2
A question about multiple(?) out of order ReleaseObject
...c")
So, are the following statements correct
1. S is 'doubly' protected from the GC by being associated both with 'v'
and because it has been added to the precious list (via a call to
R_PreserveObject without ReleaseObject being called)
2. I have another C function called cfunc2. In cfunc2, I call
R_ReleaseObject on S. S , however, is still protected from the GC, because
it is associated with 'v'
Is (1) and (2) correct?
I have not used R_protect/unprotect, because if I return from cfunc without
the equivalent number of unprotects, i get 'unbalanced stack'...
2014 Mar 07
0
Repost: (apologies for HTML post) A question about multiple(?) out of order ReleaseObject
...c")
So, are the following statements correct
1. S is 'doubly' protected from the GC by being associated both with 'v'
and because it has been added to the precious list (via a call to
R_PreserveObject without ReleaseObject being called)
2. I have another C function called cfunc2. In cfunc2, I call
R_ReleaseObject on S. S , however, is still protected from the GC, because
it is associated with 'v'
Is (1) and (2) correct?
I have not used R_protect/unprotect, because if I return from cfunc without
the equivalent number of unprotects, i get 'unbalanced stack'...
2014 Mar 07
0
Many apologies: last post: A question about multiple(?) out of order ReleaseObject
...c")
So, are the following statements correct
1. S is 'doubly' protected from the GC by being associated both with 'v'
and because it has been added to the precious list (via a call to
R_PreserveObject without ReleaseObject being called)
2. I have another C function called cfunc2. In cfunc2, I call
R_ReleaseObject on S. S , however, is still protected from the GC, because
it is associated with 'v'
Is (1) and (2) correct?
I have not used R_protect/unprotect, because if I return from cfunc without
the equivalent number of unprotects, i get 'unbalanced stack'...