From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 17E18BC6C for ; Thu, 17 Jan 2008 20:57:10 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFJCj0fAXQImh2dsb2JhbACQFwEBAQgKKYEUm34 X-IronPort-AV: E=Sophos;i="4.24,304,1196636400"; d="scan'208";a="6867023" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 17 Jan 2008 20:57:11 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0HJv6nl014982 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 17 Jan 2008 20:57:09 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFJCj0fAbSoIh2dsb2JhbACQFwEBAQgKKYEUm34 X-IronPort-AV: E=Sophos;i="4.24,304,1196636400"; d="scan'208";a="6244185" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail2-smtp-roc.national.inria.fr with ESMTP; 17 Jan 2008 20:57:10 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m0HJv86R025654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 17 Jan 2008 20:57:09 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m0HJv8Qc025652 for caml-list@inria.fr; Thu, 17 Jan 2008 20:57:08 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-099-097.pools.arcor-ip.net (dslb-088-073-099-097.pools.arcor-ip.net [88.73.99.97]) by webmail.in-berlin.de (IMP) with HTTP for ; Thu, 17 Jan 2008 20:57:08 +0100 Message-ID: <1200599828.478fb314c8bce@webmail.in-berlin.de> Date: Thu, 17 Jan 2008 20:57:08 +0100 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] Give back a Pair from C to OCaml? References: <1200583973.478f7525e7a5a@webmail.in-berlin.de> <9d3ec8300801170743k509a7c4wa9d8f490118a9653@mail.gmail.com> <1200594739.478f9f33aa51f@webmail.in-berlin.de> <20080117184150.GA14335@annexia.org> In-Reply-To: <20080117184150.GA14335@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at discorde with ID 478FB312.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 0100,:01 bandel:01 camlprim:01 camlprim:01 oreilly-book:01 gcc:01 -wall:01 ocaml:01 int's:01 unboxed:01 camlparam:01 alloc:01 Zitat von Richard Jones : > On Thu, Jan 17, 2008 at 07:32:19PM +0100, Oliver Bandel wrote: > > For example I can use "CAMLprim value (.....){...}" > > or I can throw out "CAMLprim" (which is, what I found in the > > OReilly-book). > > It's not really a good idea to "throw out" CAMLprim. It expands to > something useful on Windows. [...] OK, I will let it inside. > > > Also "value x" or "int x" are working as C-parameters > > of a function. But an OCaml-int is not the same like a > > C-int, so I would expect gcc throw out at least a warning. > > I have added "-Wall", but no warning there. > > value <> int. On normal 64 bit architectures it's defined as a long, > but basically they are not interchangable and you should always use > 'value' when you mean an OCaml value. Yes, and that was the reason why I asked ;-) So, when sseing at the C-function, that it gets parameters from OCaml, I have to use the parameters as "value".... at least this way remembering it makes sense. So I will look at "value" like on a typedef'd something. > > > Possibly that's because what is mentioned in "18.2", > > that int's are "value". > > But there is no distinction between the OCaml-ints and the > > machine's C-ints in that text. Is "an unboxed integer" meant > > to be a machine's native int, 32 Bits or 64 Bits, depending on the > > machine?. Can it be given as parameter and return value as it is? > > No. A Caml int is not represented the same way as a C int. [...] Yes, I know, but I didn't know, which "int" is meant ther in the first text-passage of 18.2. Following all the hints here from that list (and the manual and some OReilly's book reading), I have done this now: ======================================== CAMLprim value both_quad( value a, value b ) { /* declarations, CAML-allocations and conversions */ long a_quad; long b_quad; long a_c; long b_c; CAMLparam2( a, b ); CAMLlocal1( result ); result = caml_alloc (2, 0); a_c = Long_val( a ); b_c = Long_val( b ); /* now start working */ /* do the quad */ /* ----------- */ a_quad = a_c * a_c; b_quad = b_c * b_c; Store_field (result, 0, Val_long(a_quad)); Store_field (result, 1, Val_long(b_quad)); CAMLreturn( result ); } ======================================== This is only learncode, so don't await that it would make sense to implement this in realworld ;-) I only want to know if this is bugfree now, and can be used without problems. Or can I make it better somehow? TIA, Oliver