From: Marius Vollmer <mvo@zagadka.de>
Cc: guile-devel@gnu.org, Neil Jerram <neil@ossau.uklinux.net>
Subject: Re: Stack unwinding for C code
Date: Fri, 02 Jan 2004 18:38:30 +0100 [thread overview]
Message-ID: <871xqil089.fsf@zagadka.ping.de> (raw)
In-Reply-To: 3FF559C8.2040702@dirk-herrmanns-seiten.de
Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> 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
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2004-01-02 17:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-26 21:36 Stack unwinding for C code Marius Vollmer
2003-12-27 9:53 ` tomas
2003-12-27 12:11 ` Neil Jerram
2003-12-27 17:37 ` Marius Vollmer
2003-12-28 2:25 ` Tom Lord
2003-12-29 22:12 ` Marius Vollmer
2003-12-29 23:25 ` Neil Jerram
2003-12-31 0:10 ` Marius Vollmer
2004-01-02 11:45 ` Dirk Herrmann
2004-01-02 17:38 ` Marius Vollmer [this message]
2004-01-03 22:08 ` Marius Vollmer
2004-01-10 11:45 ` Dirk Herrmann
2004-01-11 1:23 ` Marius Vollmer
2004-01-06 18:37 ` Paul Jarc
2004-01-07 20:27 ` Marius Vollmer
2004-01-13 17:24 ` Rob Browning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871xqil089.fsf@zagadka.ping.de \
--to=mvo@zagadka.de \
--cc=guile-devel@gnu.org \
--cc=neil@ossau.uklinux.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).