From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: Stack unwinding for C code Date: Sat, 10 Jan 2004 12:45:58 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <3FFFE5F6.4080108@dirk-herrmanns-seiten.de> References: <87y8sz5kio.fsf@zagadka.ping.de> <87ptea40wu.fsf@zagadka.ping.de> <87brppkft6.fsf@zagadka.ping.de> <3FF559C8.2040702@dirk-herrmanns-seiten.de> <871xqil089.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1073741218 22953 80.91.224.253 (10 Jan 2004 13:26:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 10 Jan 2004 13:26:58 +0000 (UTC) Cc: guile-devel@gnu.org, Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jan 10 14:26:54 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 1AfJ8g-0005mz-00 for ; Sat, 10 Jan 2004 14:26:54 +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 1AfJDx-0004mz-9Z for guile-devel@m.gmane.org; Sat, 10 Jan 2004 08:32:21 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AfIqF-0001o5-Kz for guile-devel@gnu.org; Sat, 10 Jan 2004 08:07:51 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AfIaN-0008Kh-H7 for guile-devel@gnu.org; Sat, 10 Jan 2004 07:51:59 -0500 Original-Received: from [212.227.126.171] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AfIWc-0007NX-9S for guile-devel@gnu.org; Sat, 10 Jan 2004 07:47:34 -0500 Original-Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AfHY0-0000zl-00; Sat, 10 Jan 2004 12:44:56 +0100 Original-Received: from [80.131.36.43] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AfHXz-0006Xg-00; Sat, 10 Jan 2004 12:44:55 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en Original-To: Marius Vollmer In-Reply-To: <871xqil089.fsf@zagadka.ping.de> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:494e3e4d1bf8dc247959c49e6f1f4215 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:3176 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3176 Marius Vollmer wrote: >Dirk Herrmann writes: > > >>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. > Hmm, probably I am missing something, but wouldn't it just be possible to make the non-rewindable frame the default, and offer scm_allow_rewind as a function then? >>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... > > Huh, such casts would need to be added explicitly, both in guile and in user code. I wouldn't recommend users to use such a programming style. What we do within guile is a different thing, but even here I am much in favor of having our code as standard conforming as possible - or at least encapsulate places where it isn't. Maybe we should first wait what kinds of cleanup functions we detect to be useful within guile and then decide about this issue. Best regards Dirk _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel