From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Stack unwinding for C code Date: Fri, 02 Jan 2004 18:38:30 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <871xqil089.fsf@zagadka.ping.de> References: <87y8sz5kio.fsf@zagadka.ping.de> <87ptea40wu.fsf@zagadka.ping.de> <87brppkft6.fsf@zagadka.ping.de> <3FF559C8.2040702@dirk-herrmanns-seiten.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073065417 29370 80.91.224.253 (2 Jan 2004 17:43:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Jan 2004 17:43:37 +0000 (UTC) Cc: guile-devel@gnu.org, Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 02 18:43:27 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AcTKZ-0003eo-00 for ; Fri, 02 Jan 2004 18:43:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AcUFk-0004ZQ-Qs for guile-devel@m.gmane.org; Fri, 02 Jan 2004 13:42:32 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AcUEY-0004Hu-Jv for guile-devel@gnu.org; Fri, 02 Jan 2004 13:41:18 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AcUDj-0003Gx-Ci for guile-devel@gnu.org; Fri, 02 Jan 2004 13:40:59 -0500 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AcUDK-0002uL-HB for guile-devel@gnu.org; Fri, 02 Jan 2004 13:40:02 -0500 Original-Received: from dialin.speedway15.dip30.dokom.de ([195.253.15.30] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1AcTGK-0003CP-00 for guile-devel@gnu.org; Fri, 02 Jan 2004 18:39:04 +0100 Original-Received: (qmail 18574 invoked by uid 1000); 2 Jan 2004 17:38:31 -0000 Original-To: Dirk Herrmann User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3155 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3155 Dirk Herrmann 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