From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA11082 for caml-redistribution; Thu, 21 Oct 1999 19:11:05 +0200 (MET DST) 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 QAA30535 for ; Thu, 21 Oct 1999 16:24:09 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id QAA07937; Thu, 21 Oct 1999 16:24:01 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA32225; Thu, 21 Oct 1999 16:24:00 +0200 (MET DST) Message-ID: <19991021162400.01237@pauillac.inria.fr> Date: Thu, 21 Oct 1999 16:24:00 +0200 From: Xavier Leroy To: Edwin Young , "'caml-list@inria.fr'" Subject: Re: 32 bit integers References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Edwin Young on Mon, Oct 18, 1999 at 03:47:36PM +0100 Sender: weis > several people have been requesting features to be included in a > forthcoming O'Caml/O'Labl merge, so I thought I'd add a humble plea for > some support for untagged (presumably boxed) integers. I'm looking > mostly at camlidl, the documentation for which says: "Since the Caml int > type has one bit of tag, the conversion from IDL types int and long > loses the most significant bit on 32-bit platforms". I don't think > that's terribly satisfactory. We all agree on that. The "int" type will almost certainly remain unboxed and tagged (i.e. with one fewer bits than the platform's native integers) in the near future, but additional (boxed, untagged) integer types are certainly important for foreign-function interface. See for instance J.-C. Filliatre's "Int32" library, http://www.lri.fr/~filliatr/ftp/ocaml/int32/ (although I object to the name of that library -- on an Alpha, it implements 64-bit integers...) > If there isn't going to be a 32-bit type, > can anyone suggest a workaround (eg can I convince camlidl to map all > ints to floats)? I'm not sure you really want to do it for all ints. But you can do it on a function-per-function basis in at least two ways. Consider a C function int myfunc(int x) where the two "int" need to be represented as floats in Caml. The first way to do this is to cheat in the .idl file given to Camlidl: just declare myfunc as double myfunc(double x) and make sure that the generated C stub code knowns the real prototype of "myfunc", either by including a header file or by putting an extra prototype: quote(C, "#include ") or quote(C, "extern int myfunc(int x);") Then, the stub code generated by Camlidl will treat the argument and the result of "myfunc" as doubles, but the C compiler will insert the required int<->double coercions in the actual call to "myfunc" in the stub code. The second, more general way is to define (using typedef in the .idl file) a C type int32 synonymous for int, but represented in Caml as float: quote(C, " static value int32_c2ml(int * input) { return copy_double((double) (*input)); } static void int32_ml2c(value input, int * output) { *output = (int) Double_val(input); } ") typedef [mltype("float"),c2ml(int32_c2ml),ml2c(int32_ml2c)] int int32; int32 myfunc(int32 x); This approach is more general in that you can use other Caml types than float, e.g. Filliatre's Int32.t type. Of course, you have to provide manually the correct conversion functions (c2ml and ml2c). Hope this helps, - Xavier Leroy