From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.user Subject: Re: Passing C pointers through guile Date: Wed, 09 Jul 2008 12:48:24 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1215623141 6782 80.91.229.12 (9 Jul 2008 17:05:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jul 2008 17:05:41 +0000 (UTC) Cc: guile-user@gnu.org To: "Kjetil S. Matheussen" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jul 09 19:06:27 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KGd6N-0005ZI-2y for guile-user@m.gmane.org; Wed, 09 Jul 2008 19:05:47 +0200 Original-Received: from localhost ([127.0.0.1]:55580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KGd5V-0003WO-GR for guile-user@m.gmane.org; Wed, 09 Jul 2008 13:04:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KGd5O-0003Uh-Sp for guile-user@gnu.org; Wed, 09 Jul 2008 13:04:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KGd5M-0003Rv-II for guile-user@gnu.org; Wed, 09 Jul 2008 13:04:09 -0400 Original-Received: from [199.232.76.173] (port=38668 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KGd5M-0003RY-7G for guile-user@gnu.org; Wed, 09 Jul 2008 13:04:08 -0400 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]:59964) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KGcqG-0004JS-2M for guile-user@gnu.org; Wed, 09 Jul 2008 12:48:32 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 238FF52A5; Wed, 9 Jul 2008 12:48:24 -0400 (EDT) X-Hashcash: 1:20:080709:k.s.matheussen@notam02.no::qP3G+hHyM80SQA07:0000000000000000000000000000000000000Nvf X-Hashcash: 1:20:080709:guile-user@gnu.org::qP3G+hHyM80SQA07:00000000000000000000000000000000000000000003ohP In-Reply-To: (Kjetil S. Matheussen's message of "Sun, 06 Jul 2008 18:13:03 +0200 (CEST)") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.1 (berkeley-unix) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6634 Archived-At: "Kjetil S. Matheussen" writes: > Ludovic Court?s: >> Hi, >> >> "Maciek Godek" writes: >> >>> is there any portable and recommended way for passing C pointers around >>> in guile environment? >>> I think of something like scm_to_ptr (analogous to scm_to_int etc.). >>> Certainly such a value would be completely useless for the interpreter. >>> One can achieve simillar functionality using the aforementioned >>> scm_to_int (keeping track on the word length of the build target), >>> but it seems rather unnatural. >> >> If the goal is to make a C object pointed to by some pointer available >> to Scheme functions, the recommended (and simplest) way is to use a >> "SMOB" (see the manual for details). In practice, SMOBs incur some >> storage overhead because they hold 4 machines words, while you may only >> need one. >> >> Another possibility is to use a "uo" field in a struct: it allows you to >> have a struct field holding a machine word inaccessible to Scheme >> functions (see the "Vtables" node of the manual). >> > > I haven't heard of the "uo" field before, but at least using a SMOB > is really inconvenient, and using an unsigned long for storing > pointers is really convenient. (BTW. How does swig and gwrap handle > pointers?) > > I agree with Maciek that it would at least be mind-comforting to have > functions like scm_to_ptr/etc, although not strictly necessary, > since using integers works just fine. Does C guarantee that pointers fit in unsigned long? I suspect SMOBs are the right answer. Part of the point is to do the right thing when the scheme object is garbage collected. When discarding a pointer often one should be freeing an object or decrementing a refcount. I've use SMOBs, and they really weren't that hard once I dug in.