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 DAA22035; Sat, 28 Aug 2004 03:40:58 +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 DAA21785 for ; Sat, 28 Aug 2004 03:40:56 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i7S1esHm015854 for ; Sat, 28 Aug 2004 03:40:55 +0200 Received: from [192.168.1.200] (ppp212-216.lns2.syd3.internode.on.net [203.122.212.216]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i7S1eo4Y097881; Sat, 28 Aug 2004 11:10:51 +0930 (CST) Subject: Re: [Caml-list] C++ Throws From: skaller Reply-To: skaller@users.sourceforge.net To: David McClain Cc: Brian Hurt , caml-list In-Reply-To: <000901c48c93$9bc9eec0$0201000a@dylan> References: <000901c48c93$9bc9eec0$0201000a@dylan> Content-Type: text/plain Message-Id: <1093657249.15255.1712.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Aug 2004 11:40:50 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 412FE2A6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 mcclain:01 generic:01 'return':99 unwind:01 unwind:01 debugging:01 abort:01 abort:01 generic:01 implemented:01 9660:01 glebe:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 2004-08-28 at 10:11, David McClain wrote: > Hi Brian, > > Yes, that technique is the one that I said previously works just fine. I was > hoping for a higher level generic handler, instead of wrapping each > individual lib call with this try-catch block. > > I have been doing C++ to OCaml for years now with no difficulty. The catch > here is that OCaml appears to be interposing between the established higher > level catch handlers and the source of the throw exceptions. It appears to > insist on not allowing any lower dynamic exceptions to propagate above its > interface with a C call. No, I doubt that. What's actually happening is quite the opposite. C++ stack unwinding involves synchonously destroying stack objects and NOT returning control until the handler is reached. But you've stuck some Ocaml stack frames in the way. Far from Ocaml 'grabbing control', it isn't doing anything. Ocaml isn't ever getting control -- C++ knows nothing and just keeps going -- it doesn't execute the 'return' instruction for the callers program counter, it throws it away. Actually it's more complex than that -- EH has two jobs: (a) locate the handler (b) unwind the stack up to it then give it control It is allowed to unwind the stack whilst looking for the handler. It is also allowed to locate the handler FIRST, and THEN unwind. In particular if there is NO handler, it is allowed to core dump on the spot without unwinding anything -- the reason being that you then get a dump which actually includes debugging information :) Either way it is C++ which will either abort() because it can't find a handler, or corrupt your system and lock up or crash, if it it actually get stuck misinterpreting the Ocaml stack frames either during unwinding or trying to find the stack frames .. don't even count on abort() being called. I think it is possible to write generic handler, but only if you have detailed implemention details from you compiler vendor on how EH is implemented on your platform :( -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners