From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 9B5D9BB91 for ; Thu, 21 Jul 2005 12:22:03 +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 j6LAM2cT001556 for ; Thu, 21 Jul 2005 12:22:03 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA12168 for ; Thu, 21 Jul 2005 12:22:02 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6LAM0uV001553 for ; Thu, 21 Jul 2005 12:22:01 +0200 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id j6LALwoK015265; Thu, 21 Jul 2005 19:21:58 +0900 (JST) Date: Thu, 21 Jul 2005 19:21:54 +0900 (JST) Message-Id: <20050721.192154.31710299.garrigue@math.nagoya-u.ac.jp> To: roessler@rftp.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] A pair of "Interfacing with C" questions From: Jacques Garrigue In-Reply-To: <42DF2A64.4000600@rftp.com> References: <42DF2A64.4000600@rftp.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42DF774A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42DF7748.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 interfacing:01 widget:01 widget:01 terminating:01 byte:01 ocaml:01 pointers:01 nativeint:01 mlvalues:01 nativeint:01 pointer:01 ocaml:01 aligned:01 pointers:01 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 From: Robert Roessler > 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. No problem currently: for C compatibility all ocaml strings have a 0 after their end. Nobody can give "future" guarantees, but if there is a change at this level, I assume this would be well publicised. > 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. If you look at mlvalues.h you will see that nativeint is define as long int. So this should be the natural format for a pointer. The other option is to use store them in an ocaml int, without any conversion, as 4-byte aligned pointers outside of the heap are ignored by the GC. But this has some pitfalls, as some dangling pointers may end up pointing to a newly allocated heap area. This is also less "future proof", as the representation of ocaml integers might change someday. Another advantage of nativeint is that they are custom block, so you just have to change the allocation to make them GC-aware. This is why I converted all pointers to custom-format blocks in lablgtk. > 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? This is certainly currently the case, and without a radical change in the approach to polymorphism, all "basic" ocaml types must have the same size, and for practical reasons it is good that machine pointers fit in this size. I suppose this does not exclude compiling ocaml in 32-bit mode on 64-bit machines that support such a mode, but even in this case this supposes that (32-bit) pointers fit in an ocaml memory unit. Jacques Garrigue