Re: Stack unwinding for C code

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> I like this style of interface for its simplicity.

Ok!  Given all the feedback, I'll design/document it as the general
mechanism for dealing with dynamic extents from C.

> But, I am somewhat confused since in your proposal below you don't
> suggest this style of interface, but instead describe
> scm_begin_frame as receiving an additional argument with flags.

Yes, that was confusing, sorry.

> I wouldn't prefer any of the two solutions, but I am currently not
> sure what you actually suggest - especially since in the example
> given below you don't pass any argument to scm_begin_frame.

The first variant (with scm_prevent_rewind) would be more elegant from
an implementational point of view.  The latter (with
SCM_F_REWINDABLE_FRAME) leads to a more desirable default behavior.  I
think people should explicitely allow rewinding when they have unwind
handlers.

So, I prefer the latter variant.

>>- C Function: void scm_begin_frame (int flags)
>>
>>  Starts a new frame and makes it the 'current' one.  FLAGS determines
>>  the default behavior of the frame.  For normal frames, use 0.  This
>>  will result in a frame that can not be reentered with a captured
>>  continuation.  See below.
>>
>>  The frame is ended either implicitly when a non-local exit happens,
>>  or explicitly with scm_end_frame.
>>
> If this style of API is used (that is, passing a 'flags' argument to
> scm_begin_frame instead of having separate functions like
> scm_prevent_rewind and similar), then I suggest to use an enumeration
> type with all possible flags instead of an int type. This improves
> both type safety and readability of the code using
> scm_begin_frame. The same applies to the 'explicit' argument to
> scm_on_unwind and scm_on_rewind.

Yep, agreed.

> It is a nice coincidence that 'free' matches the void (*func) (void
> *) signature, especially since free will probably be one of the most
> frequently used functions with scm_on_unwind. fclose, however, does
> not match and is another candidate that may be commonly
> used. Unfortunately it wouldn't be standard conforming to just cast
> fclose to match the signature.

Is that a theoretical problem or do indeed platforms exist where you
can't cast fclose to (void (*)(void *))?

If it is only theoretical, I'm inclined not to worry about it...

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405