From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: David Pirotte Newsgroups: gmane.lisp.guile.devel Subject: Re: make-c-struct and pointer->string Date: Tue, 2 Apr 2019 15:03:42 -0300 Message-ID: <20190402150342.7164ddae@capac> References: <20190326101419.340081fc@capac> <877ecg85xm.fsf@netris.org> <20190331073830.41897916@capac> <87v9zy6rd8.fsf@netris.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/zNW5NPL8kmjtf6rgug..nV6"; protocol="application/pgp-signature" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="72271"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 02 20:04:20 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 1hBNlj-000Idr-7P for guile-devel@m.gmane.org; Tue, 02 Apr 2019 20:04:19 +0200 Original-Received: from localhost ([127.0.0.1]:50116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBNlh-00046x-PZ for guile-devel@m.gmane.org; Tue, 02 Apr 2019 14:04:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBNlM-00046h-Dg for guile-devel@gnu.org; Tue, 02 Apr 2019 14:03:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBNlK-00062W-BB for guile-devel@gnu.org; Tue, 02 Apr 2019 14:03:55 -0400 Original-Received: from maximusconfessor.all2all.org ([79.99.200.102]:49554) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hBNlH-0005ut-EM for guile-devel@gnu.org; Tue, 02 Apr 2019 14:03:53 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by maximusconfessor.all2all.org (Postfix) with ESMTP id 929F71BE00A9; Tue, 2 Apr 2019 20:03:48 +0200 (CEST) Original-Received: from maximusconfessor.all2all.org ([127.0.0.1]) by localhost (maximusconfessor.all2all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZdADFjnp0yF; Tue, 2 Apr 2019 20:03:48 +0200 (CEST) Original-Received: from capac (unknown [179.210.18.152]) by maximusconfessor.all2all.org (Postfix) with ESMTPSA id D993D1BE0099; Tue, 2 Apr 2019 20:03:47 +0200 (CEST) In-Reply-To: <87v9zy6rd8.fsf@netris.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 79.99.200.102 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:19874 Archived-At: --Sig_/zNW5NPL8kmjtf6rgug..nV6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello Mark, > >> 'make-c-struct' copies the C pointers from those foreign pointer obje= cts, but > >> not not keep a reference to the objects themselves. =20 > > To me, this sounds very counter intuitive, actually, it sounds like a b= ug, > > 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? =20 > 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. Answering the second of your 2 emails, but I did read the first as well ... I agree with you, I think I somehow was only looking at one (of the many) w= ay users may use make-c-struct/parse-c-struct, and indeed I now see that my request = would even lead to mem problem, since most of the time, C may change these pointe= rs or any other struct field(s) content ... Thanks again for your time and very good explanations. Cheers, David --Sig_/zNW5NPL8kmjtf6rgug..nV6 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhCJlRZtBM3furJHe83T9k6MFetcFAlyjo/4ACgkQ83T9k6MF etfYugf/YQQ8oxwYPWRDNTjhm5R0pI1/LavLKJeNHo/moMm0fdRVblRBBTxwy6ol vItkWcZ/gbpDwfEGSp1OfsiMD8dvlbLYvTk4PRL5CBNDzzfSzFTxtEIOzPCe4Oum 8k7EfxGfiw7xzXgf+4CaOd44ijmBBlyAQBbzMhfdT8/0NHXkpPMV6kf75Yn0SEDP yZXaCh8KkE/qRYIo4faIsno4sKzUrS3bJwAX/Z/tYQaR4yucEAsBRgdzc6Z9cJpN k/1HE86JfZFh+HRpGROW+2k8xzzIlbcclAwmEnlWaCgxrYEPc7BaGIyHiW4xJ8Zd XiiRTfjxQoKucrrN0YiS1HfLL2/lfw== =UTro -----END PGP SIGNATURE----- --Sig_/zNW5NPL8kmjtf6rgug..nV6--