From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p7GH8bjl027784 for ; Tue, 16 Aug 2011 19:08:38 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosBABujSk7RVdeqkGdsb2JhbAA1DBaoIQgUAQEBAQkJDQcUBCGBQAEBAQEDEgIJIwEbHgMMBgULOyMRAQUBHAY1h1KbXAqMN4JVhTk7iG0CAwaDGgGCSF8Eh1+LM4Y0hiU8g34 X-IronPort-AV: E=Sophos;i="4.68,234,1312149600"; d="sig'?scan'208";a="105608012" Received: from mail-ey0-f170.google.com ([209.85.215.170]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Aug 2011 19:08:38 +0200 Received: by eyd10 with SMTP id 10so116420eyd.15 for ; Tue, 16 Aug 2011 10:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-pgp-agent :x-mailer; bh=n2ZXeOPmWWCamLeqBac/i75RDPA60Ejfe3P67H4z8BA=; b=o8472J4h6POo0nZPCGZZUL0qjtE5YXdPz7DNwx6T/dlj3S9nfOO0G93zc/cYhIatHb TB5NUyWl822JoGTYOev9zieZ/ieo3pqGLARDpPIMkaWcS3Rys+aZtKqh3PISsIskXnkq AVJmyLRDEA30TQWjIUjS4Gdw97ysElwA2bTNE= Received: by 10.213.7.218 with SMTP id e26mr30808ebe.80.1313514517413; Tue, 16 Aug 2011 10:08:37 -0700 (PDT) Received: from dhcp-129-105-65-159.astro.northwestern.edu (dhcp-129-105-65-159.astro.northwestern.edu [129.105.65.159]) by mx.google.com with ESMTPS id u43sm136607eef.63.2011.08.16.10.08.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Aug 2011 10:08:36 -0700 (PDT) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7-199865055" Mime-Version: 1.0 (Apple Message framework v1084) From: "Will M. Farr" In-Reply-To: Date: Tue, 16 Aug 2011 12:08:33 -0500 Content-Transfer-Encoding: 7bit Message-Id: <169845B3-E514-4D0A-B571-29BA22493CB5@gmail.com> References: <20110816152550.GA21081@annexia.org> <20110816155137.GA18365@ccellier.rd.securactive.lan> <20110816161042.GA31932@annexia.org> <20110816162205.GC31932@annexia.org> <20110816162719.GD31932@annexia.org> <4E4A9C17.7060605@gmail.com> To: Caml List X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Subject: Re: [Caml-list] Re: Interfacing with C: bad practice This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-7-199865055 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii An aside: In case people want to crib the language, the Racket (formerly PL= T Scheme) manual contains a warning about exactly this problem in the appen= ded text (Section 3.1.2 of the "Inside: Racket C API" at http://docs.racket= -lang.org/inside/im_memoryalloc.html#(part._im~3a3m~3astack) ). It shouldn= 't be hard to adapt the discussion to something appropriate for the OCaml m= anual: --------------------------------- The 3m collector needs to know the address of every local or temporary poin= ter within a function call at any point when a collection can be triggered.= Beware that nested function calls can hide temporary pointers; for example= , in scheme_make_pair(scheme_make_pair(scheme_true, scheme_false), scheme_make_pair(scheme_false, scheme_true)) the result from one scheme_make_pair call is on the stack or in a register = during the other call toscheme_make_pair; this pointer must be exposed to t= he garbage collection and made subject to update. Simply changing the code = to tmp =3D scheme_make_pair(scheme_true, scheme_false); scheme_make_pair(tmp, scheme_make_pair(scheme_false, scheme_true)) does not expose all pointers, since tmp must be evaluated before the second= call toscheme_make_pair. In general, the above code must be converted to t= he form tmp1 =3D scheme_make_pair(scheme_true, scheme_false); tmp2 =3D scheme_make_pair(scheme_true, scheme_false); scheme_make_pair(tmp1, tmp2); and this is converted form must be instrumented to register tmp1 and tmp2. = The final result might be { Scheme_Object *tmp1 =3D NULL, *tmp2 =3D NULL, *result; MZ_GC_DECL_REG(2); =20=20 MZ_GC_VAR_IN_REG(0, tmp1); MZ_GC_VAR_IN_REG(1, tmp2); MZ_GC_REG(); =20=20 tmp1 =3D scheme_make_pair(scheme_true, scheme_false); tmp2 =3D scheme_make_pair(scheme_true, scheme_false); result =3D scheme_make_pair(tmp1, tmp2); =20=20 MZ_GC_UNREG(); =20=20 return result; } Notice that result is not registered above. The MZ_GC_UNREG macro cannot tr= igger a garbage collection, so the result variable is never live during a p= otential collection. Note also that tmp1 andtmp2 are initialized with NULL,= so that they always contain a pointer whenever a collection is possible. --------------------------------------------= --Apple-Mail-7-199865055 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk5KpBIACgkQ1IoZbWY+dGzB/ACeN3SsJOXiaNLVRGe/qh9TGv7N KBMAoKY8LLW4wE4KcAYq6T8fQCTQ/HBA =vZ+M -----END PGP SIGNATURE----- --Apple-Mail-7-199865055--