From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id A9ADABB91 for ; Thu, 21 Jul 2005 06:53:36 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6L4raw3002262 for ; Thu, 21 Jul 2005 06:53:36 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA08970 for ; Thu, 21 Jul 2005 06:53:35 +0200 (MET DST) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by nez-perce.inria.fr (8.13.0/8.13.0) with SMTP id j6L4rYaX004797 for ; Thu, 21 Jul 2005 06:53:35 +0200 Received: (qmail 63465 invoked from network); 21 Jul 2005 04:53:34 -0000 Received: from unknown (HELO ?192.168.1.100?) (rftp@pacbell.net@63.194.18.166 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 21 Jul 2005 04:53:33 -0000 Message-ID: <42DF2A64.4000600@rftp.com> Date: Wed, 20 Jul 2005 21:53:56 -0700 From: Robert Roessler Organization: Robert's High-performance Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caml-list Subject: A pair of "Interfacing with C" questions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42DF2A50.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42DF2A4E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; interfacing:01 widget:01 widget:01 terminating:01 byte:01 byte:01 granularity:01 pointers:01 nativeint:01 nativeint:01 model:01 pointers:01 non-issue:01 ...:98 ...:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 1) in wrapping a large widget with multiple interfaces using "strings", I sometimes allow the widget to copy a C-string into a Caml-allocated string - INCLUDING "overwriting" the terminating zero byte with zero... I wanted to make sure this was not seen as a major problem. As I understand the Caml runtime's use of strings (at least one zero byte always being present), this does not seem like a problem to me - and until memory protection granularity practices change a lot, there should not be any trouble there... :) 2) this is about "future-proofing" (at the source level) code which interfaces with external [foreign] components and needs to store and pass around "opaque pointers": what is the best base Caml data type to use? I currently use type opaque_ptr = int32 I assume the other choices include int64, nativeint, or even int. int64 - good if you know you are dealing with 64-bit values, obviously not suitable in the general case. nativeint - this looks promising, as long as you do not need to deal with a 64-bit-int/32-bit-pointer model... would it be safe to assume that in any 64-bit Caml implementation, ints/pointers/"values" will ALL be 64-bit? int - there clearly is a restriction on using only pointers with the low bit set to zero; if you can stipulate that this is a non-issue, then you can just SET/CLEAR the low bit at the Caml/C boundary and then be able to safely store to and retrieve from Caml "value" fields (I think). So... is the winner int or nativeint? Or ? And yes, I know that using int will avoid an extra allocation... but are there other considerations not represented here? Any relevant insights will be appreciated. :) Robert Roessler roessler@rftp.com http://www.rftp.com