We do have a mechanism in the base C code for ensuring that cleanup
code is run on longjmps; we wouldn't want to expose that in the API in
its current form, but could make a wrapper around it available -- I'll
make a note to look into it. But as Simon describes there are good
options available for
Jeroen,
I agree that it may be useful to have some kind of "finally"-like
infrastructure. However, in the use cases you list there are already ways to do
that - the same way that R_alloc uses. First, you don't need to call UNPROTECT
- the whole point is that the protection stack is automaticall
On 24/11/2015 6:20 PM, Andrew Piskorski wrote:
On Tue, Nov 24, 2015 at 12:10:12AM +0100, Jeroen Ooms wrote:
Currently it is all to easy for package authors to introduce a memory
leak or stack imbalance by calling Rf_error() or
R_CheckUserInterrupt() in a way that skips over the usual cleanup
st
On Tue, Nov 24, 2015 at 12:10:12AM +0100, Jeroen Ooms wrote:
> Currently it is all to easy for package authors to introduce a memory
> leak or stack imbalance by calling Rf_error() or
> R_CheckUserInterrupt() in a way that skips over the usual cleanup
> steps.
I have a more modest request: Pleas
