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 02:23:59 -0400 Message-ID: <8736n28cpx.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="144744"; 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 08:26:55 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 1hAqPG-000bXU-CP for guile-devel@m.gmane.org; Mon, 01 Apr 2019 08:26:54 +0200 Original-Received: from localhost ([127.0.0.1]:34456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAqPF-0008E4-7i for guile-devel@m.gmane.org; Mon, 01 Apr 2019 02:26:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAqO6-0007Al-1q for guile-devel@gnu.org; Mon, 01 Apr 2019 02:25:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hAqO4-0004cA-Re for guile-devel@gnu.org; Mon, 01 Apr 2019 02:25:42 -0400 Original-Received: from world.peace.net ([64.112.178.59]:38310) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hAqO4-0004YX-NB for guile-devel@gnu.org; Mon, 01 Apr 2019 02:25:40 -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 1hAqNt-0005jp-CD; Mon, 01 Apr 2019 02:25:29 -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:19872 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? It's a reasonable suggestion, and I agree that the documentation should be clarified on these points, which are quite tricky. I thought about what would be required to implement your suggestion and quickly ran into difficulties, and also the understanding that this is not always the right behavior. First of all, the address of the foreign pointer object is what we would need to keep a reference to, and that's not the same as the C pointer wrapped within that foreign pointer object. This raises the question of where to store these additional references, since we can't store them in any of the C struct fields defined by the user. The worse problem is that there's no way to keep these extra references in sync with the C pointers in the C struct. The C code might overwrite one of those pointers, and move them to a different structure somewhere else. Also note that in many cases, foreign pointer objects are used only transiently to copy a C pointer from one place to another. If we implemented your suggestion, these otherwise transient foreign pointer objects would be kept alive for no purpose. The other thing is that even if we had these suggested semantics, you would still need to arrange to hold a reference to the foreign pointer object returned by 'make-c-struct'. It seems to me that the hard part is deciding when these references can be released. Once you've made that determination, releasing N references is almost as easy as releasing 1 reference. Let me ask you this: in your current use case, what _should_ be the policy on when to free those C strings? What will become of that C structure allocated with 'make-c-struct', and how will you find out when the C code no longer needs it? Regards, Mark