From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 76C537EE94 for ; Sun, 30 Dec 2012 15:36:58 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.46; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.46 as permitted sender) identity=mailfrom; client-ip=209.85.214.46; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f46.google.com) identity=helo; client-ip=209.85.214.46; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-bk0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsBAHhQ4FDRVdYujWdsb2JhbAAqGhaqepJFCBYOAQEBAQkJCwkSBiOCHgEBBQw0ARsSCwEDDAYFCw0NISIBEQEFAQoSBhMSh24BAw8MLJlSjDOCe4N0ChknAwpZh2EBBQyMS4RDA5YMgRyNTBYphBY X-IronPort-AV: E=Sophos;i="4.84,381,1355094000"; d="scan'208";a="167103361" Received: from mail-bk0-f46.google.com ([209.85.214.46]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Dec 2012 15:36:57 +0100 Received: by mail-bk0-f46.google.com with SMTP id q16so5270738bkw.19 for ; Sun, 30 Dec 2012 06:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=H4l8FUj8E2g7mLPoKHM2ED8Pn7NOaoNZ4/LfqrctUDQ=; b=HByNBxSrEnIkyhg3rg1nVtiGgQaa3l/7IqfNr1qixDcbWaULBay+zwgHZMLkMPXazA XixDPs9JKwmn3NI5MQRI9ySTKG3/3CHFrLfO8/tnYIsK79Y9znBmhVbNjqPLHHDDBrpR FCI4FR6ybnF8AAMgUjRs6VATfxDuyvinhY24GmpqTz4mkXOIVgqDph1dkZ8NpcpLXQ/e PZijaJhzekCNYK6XG6P7hA4HrbXq2KPOM6HJ/T90SIQiNS65A3pX8+XPBDBQFM3atVya pssz8/fNrCbndIQWve9UuoncEAmudTxWX7LCeUm1GLfA/mfChSvrNbIVjJgDJO22LUsa /3LQ== Received: by 10.204.13.28 with SMTP id z28mr18309538bkz.113.1356878216773; Sun, 30 Dec 2012 06:36:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.236.134 with HTTP; Sun, 30 Dec 2012 06:36:16 -0800 (PST) In-Reply-To: <20121230151941.7d2261d1@xivilization.net> References: <20121230140823.20f39bcd@xivilization.net> <50E04922.207@etorok.net> <20121230151941.7d2261d1@xivilization.net> From: Gabriel Scherer Date: Sun, 30 Dec 2012 15:36:16 +0100 Message-ID: To: Marek Kubica Cc: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= , caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] C interop: Return values in parameters References are a derived concept defined as: type 'a ref =3D { mutable contents : 'a } You can update them from the C side just as you would handle a polymorphic record, with Field and Store_field. In the code you show, the OCaml value corresponding to the pointer is exactly the pointer, hidden as a 'value' type. This is correct as OCaml detects out-of-(OCaml)-heap pointer. However, if you used a custom block instead ( http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual033.html#toc150 ), OCaml would do the boxing for you: Data_custom_val(v) already returns a pointer than can be dereferenced or mutated. I think you have a choice between using references explicitly for those functions of the API that mutate input references, or uniformly representing this type of data as a custom block. The latter option may be valuable if you have uses for the other features of custom blocks, eg. the user-defined comparison and finalization operations, and probably not worth the trouble otherwise. Finally, explicitly using references to signal mutability in some part of your API is probably clearer and a better design. On Sun, Dec 30, 2012 at 3:19 PM, Marek Kubica wrot= e: > Hi, > > Thanks for your help. > > On Sun, 30 Dec 2012 16:01:06 +0200 > T=F6r=F6k Edwin wrote: > >> Use a ' ref' for the parameter (or a record with a mutable >> field) on the OCaml side, and you can update the field on the C side >> then. > > I was thinking about the same thing and checked > > http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php > and > http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual033.html > > and couldn't find how to modify a ref value from C. > > My code looks like this: > > CAMLprim value ost_read_next_header(value archive, value entry) > { > struct archive* handle =3D (struct archive*)archive; > struct archive_entry* ent =3D (struct archive_entry*)entry; > printf("ent: %p\n", ent); > int retval =3D archive_read_next_header(handle, &ent); > // ent changed > printf("ent: %p\n", ent); > entry =3D (value)ent; > return Val_int(retval); > } > > And the second parameter is defined as "entry ref", yet when I look at > the resulting value from OCaml, the ref's value did not change: > > let entry =3D ref (Archive.entry_new ()) in > Archive.print_pointer !entry; > ... > ignore (Archive.read_next_header handle entry); > Archive.print_pointer !entry; > > It still points to the same value that my Archive.entry_new returned. > >> Or if your C type is not actually void*, and your C function doesn't >> have side-effects (besides updating ptr) you can also make the OCaml >> function return the actual value, and raise an exception if the >> function failed. > > I thought about this, but I have a number of these functions and some > have more than one return parameter, so I'd need to return a tuple at > least. I plan to make this wrapper as close to C and low-level, so I > can write a proper high-level wrapper on top. > > If the ref-appoach does not get me anywhere, I might still do this. > > regards, > Marek > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs