From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id GAA25929; Mon, 4 Jun 2001 06:01:29 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA25957 for ; Mon, 4 Jun 2001 06:01:27 +0200 (MET DST) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id f5441PX06429 for ; Mon, 4 Jun 2001 06:01:25 +0200 (MET DST) Received: (qmail 96466 invoked from network); 4 Jun 2001 04:01:23 -0000 Received: from unknown (HELO w2kpro) ([64.81.246.34]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Jun 2001 04:01:23 -0000 Message-ID: <008101c0ecab$148c84d0$22f65140@w2kpro> From: "Harry Chomsky" To: "Daniel de Rauglaudre" Cc: "Caml list" References: <00c301c0ea11$17a38570$22f65140@w2kpro> <20010601001301.A11836@verdot.inria.fr> <00ff01c0ea25$68d716f0$22f65140@w2kpro> <20010601134802.G15012@verdot.inria.fr> Subject: Re: [Caml-list] Win32 API Date: Sun, 3 Jun 2001 21:01:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > OK, I think I'm understanding this better now. So if a C function does all > > of its work using simple macros like Val_int then it's ok, but if it does > > anything that might cause the OCaml runtime to allocate memory, then it has > > to use the CAMLparam and CAMLreturn macros as described in the > > documentation. Is that right? > > Right. And CAMLlocal also. Now, what happens in the following situation? some_function(alloc_something(), alloc_something_else()); I haven't declared any C variables here, so we might think there are no GC problems. But there are two allocations here, and it looks like the second one might invalidate the result of the first one. So maybe this is unsafe after all. Here's an improved version: CAMLlocal1(v); v = alloc_something(); some_function(v, alloc_something_else()); Now if the second allocation invalidates the result of the first, the runtime will update the variable v. But what if the value of v was already pushed onto the stack before the second allocation occurred? (I can't remember how the C calling convention works, so this might make more sense if you reverse the order of the parameters.) The runtime updates the *variable* v, but it doesn't know about the second copy of that value that's on the stack, so it doesn't update that, and the function still gets called with an invalid parameter. So the only safe solution is to go all the way: CAMLlocal2(v1, v2); v1 = alloc_something(); v2 = alloc_something_else(); some_function(v1, v2); Is this correct? ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr