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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id ADFD47FE07 for ; Wed, 3 Feb 2016 15:38:05 +0100 (CET) IronPort-PHdr: 9a23:sOmKRRASC3u4VaypueNfUyQJP3N1i/DPJgcQr6AfoPdwSP79pcbcNUDSrc9gkEXOFd2CrakU1KyP7eu8ACQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTokbnssMGKKyxzxxODIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu5NznlpL1/A1zz158O34YIxu38I46FppIZ8VvDxdqE8BaFDAS49ezQ+7cjv8B3CVhen530GU2xQnAAeUCbf6xSvdZfrszDmsfJ97wkEMsDsBeQ/WS6j9LtsUB+uiCAKODMj2H3Kz8Z9lqZaplStqkoskMbvfIiJOa8mLevmdtQASD8ZUw== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=christoph.hoeger@tu-berlin.de; spf=None smtp.mailfrom=christoph.hoeger@tu-berlin.de; spf=None smtp.helo=postmaster@mail.tu-berlin.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=pra; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=mailfrom; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.tu-berlin.de) identity=helo; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="postmaster@mail.tu-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWAABzD7JWnCEHlYJehHmIW7EKAQ2BZYYNAoFHOBQBAQEBAQEBARABAQEBAQgLCQkhLoItghUBAQMBIwQLAUUGCwsaAgUWCwICCQMCAQIBRQYNBgIBAYgPCASwcI8JKnuJTocygToFkmyEBY8oh0GFVYVwiFAeAQGCQhQIgUlpiWsBAQE X-IPAS-Result: A0CWAABzD7JWnCEHlYJehHmIW7EKAQ2BZYYNAoFHOBQBAQEBAQEBARABAQEBAQgLCQkhLoItghUBAQMBIwQLAUUGCwsaAgUWCwICCQMCAQIBRQYNBgIBAYgPCASwcI8JKnuJTocygToFkmyEBY8oh0GFVYVwiFAeAQGCQhQIgUlpiWsBAQE X-IronPort-AV: E=Sophos;i="5.22,391,1449529200"; d="scan'208";a="200979026" Received: from mail.tu-berlin.de ([130.149.7.33]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2016 15:38:04 +0100 X-tubIT-Incoming-IP: 91.66.48.164 Received: from ip5b4230a4.dynamic.kabel-deutschland.de ([91.66.48.164] helo=[192.168.178.42]) by mail.tu-berlin.de (exim-4.76/mailfrontend-8) with esmtpsa [UNKNOWN:AES128-SHA:128] for id 1aQyZG-0001XM-ju; Wed, 03 Feb 2016 15:38:03 +0100 References: <56B1DC54.1060109@tu-berlin.de> <56B1EC33.2090303@tu-berlin.de> To: caml users From: =?UTF-8?Q?Christoph_H=c3=b6ger?= Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_Berlin?= Message-ID: <56B210C9.3050703@tu-berlin.de> Date: Wed, 3 Feb 2016 15:38:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.3.142716 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Subject: Re: [Caml-list] Save callbacks from OCaml to C Am 03.02.2016 um 14:49 schrieb Jeremie Dimino: > CAMLparam0 is for when you have no [value] arguments but have some local > [value] variables. CAMLlocalN must be preceded by a CAMLparamY, that's > why you need the CAMLparam0. Thanks. I wasn't sure about that, since I tried before and my stack values were overwritten (I assumed it was the GC at that time). > So if the GC ends up moving [g], it needs to know that it must update > [user_data->g] to point to the new location. Even more subtle. user_data was a pointer to the body of a custom allocated block. My huge mistake was to use the custom_val directly (i.e. I allocated n bytes and passed around the pointer to these n bytes). As it turns out, the GC may move a custom block by memcopying its body. So in that body I needed pointers to allocated data not the allocated data itself. Thanks again! -- Christoph Höger Technische Universität Berlin Fakultät IV - Elektrotechnik und Informatik Übersetzerbau und Programmiersprachen Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin Tel.: +49 (30) 314-24890 E-Mail: christoph.hoeger@tu-berlin.de