From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Han-Wen Nienhuys Newsgroups: gmane.lisp.guile.devel Subject: Re: port initialization? Date: Thu, 8 Aug 2002 22:54:22 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <15698.55934.287636.6739@blauw.xs4all.nl> References: <15693.15724.416839.636665@blauw.xs4all.nl> <15698.51215.103077.669940@blauw.xs4all.nl> <87lm7h2iu1.fsf@zagadka.ping.de> Reply-To: hanwen@cs.uu.nl NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1028839882 13324 127.0.0.1 (8 Aug 2002 20:51:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 8 Aug 2002 20:51:22 +0000 (UTC) Cc: Marius Vollmer , guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17cuFd-0003Sm-00 for ; Thu, 08 Aug 2002 22:51:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17cuGL-0007pm-00; Thu, 08 Aug 2002 16:52:05 -0400 Original-Received: from smtpzilla5.xs4all.nl ([194.109.127.141]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17cuFQ-0007lj-00 for ; Thu, 08 Aug 2002 16:51:08 -0400 Original-Received: from blauw.xs4all.nl (blauw.xs4all.nl [213.84.26.127]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g78Kp6NI003250; Thu, 8 Aug 2002 22:51:06 +0200 (CEST) Original-To: Marius Vollmer In-Reply-To: <87lm7h2iu1.fsf@zagadka.ping.de> X-Mailer: VM 7.05 under Emacs 21.2.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1025 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1025 mvo@zagadka.ping.de writes: > > >Yes, but the GC will not notice since "z" still refers to it and > > >therefore the port cell wont be freedo > > > > That's not what I meant: z is a heap cell containing a null > > pointer. GC-ing it will dump core. > > Sure? Closed ports do contain NULL pointers as well and the GC can > handle them just fine. The second word of a cell that is tagged as a > port is not a SCM. The GC knows that and will not try to follow it > (except when freeing a port cell but then only when it is not flagged > as closed). Am I missing somthing? Perhaps I'm missing something. I think that having null pointers in the heap is not a good idea, but of course you're right (just checked), there are lots of checks to prevent a core dump. > > > > SCM port = scm_cell (scm_tc16_port, newport); > > > > newport->port = port; > > > > .. > > > > } > > > / > > > This will leak newport when the call to scm_cell throws. > > > > scm_cell throws, what do you mean? > > I meant, when we run out of memory. Does scm_cell signal an error > then (als scm_misc_error), or does it just abort the process? All errors in the GC cause an abort(), AFAIK. (checking) No, there are some out-of-memory errors, and scm_misc_errors, mainly for programming errors (rogue pointer, undefined smob type, etc.). I think that this is a bad idea. Unwinding the stack (which is done in scm_error, right?) wlil stop the GC halfway. I think this will lead unpredictable results. An out-of-memory error should be handled gracefully, I would says although I can't really imagine how (there is little code that can run, if you can't alloc a string or a cell, right?) -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel