From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: make-c-struct and pointer->string Date: Mon, 01 Apr 2019 04:50:32 -0400 Message-ID: <87v9zy6rd8.fsf@netris.org> References: <20190326101419.340081fc@capac> <877ecg85xm.fsf@netris.org> <20190331073830.41897916@capac> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="213793"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-devel To: David Pirotte Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Apr 01 10:52:10 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hAsfq-000tSQ-3H for guile-devel@m.gmane.org; Mon, 01 Apr 2019 10:52:10 +0200 Original-Received: from localhost ([127.0.0.1]:47593 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAsfp-0002FN-13 for guile-devel@m.gmane.org; Mon, 01 Apr 2019 04:52:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAsfi-0002Cl-5H for guile-devel@gnu.org; Mon, 01 Apr 2019 04:52:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hAsfh-0006Fw-49 for guile-devel@gnu.org; Mon, 01 Apr 2019 04:52:02 -0400 Original-Received: from world.peace.net ([64.112.178.59]:38478) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hAsfg-0006Fl-VB for guile-devel@gnu.org; Mon, 01 Apr 2019 04:52:01 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hAsff-0006Yn-Si; Mon, 01 Apr 2019 04:51:59 -0400 In-Reply-To: <20190331073830.41897916@capac> (David Pirotte's message of "Sun, 31 Mar 2019 07:38:30 -0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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 Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19873 Archived-At: Hi David, David Pirotte writes: >> 'make-c-struct' copies the C pointers from those foreign pointer objects, but not >> not keep a reference to the objects themselves. > > To me, this sounds very counter intuitive, actually, it sounds like a bug, > make-c-struct should be holding a reference to the pointers it receives: i seems to > me that only when the c-struct itself becomes unreachable, that these pointers could > be freed? In my previous email I described some practical difficulties with implementing this suggestion, but I should rather emphasize a more important point: 'make-c-struct' is ultimately meant for passing data to C, and in general you should assume that Boehm GC will _not_ see references from C data structures to your GC-allocated objects. In fact, Boehm GC does _not_ scan objects allocated using C 'malloc', nor C++ 'new', nor 'make-c-struct'. So, for purposes of garbage collection, you should normally assume that passing pointers to C land is equivalent to passing them to a block hole. In general, when passing GC-allocated objects to C code, unless the C code in question was written with Boehm GC in mind, you must always think about how long the object must be kept alive, and arrange to keep a reference to it for at least that long, and preferably no longer than necessary or else you'll have space leaks. I'm open to suggestions of how to make this better, although I'm also fairly confident that interfacing between GC-managed and non-GC-managed code is a thorny problem with no silver bullets. Mark