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 SAA12895; Fri, 13 Dec 2002 18:05:51 +0100 (MET) 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 SAA12891 for ; Fri, 13 Dec 2002 18:05:50 +0100 (MET) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from opus.davidb.org (66-27-72-19.san.rr.com [66.27.72.19]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id gBDH5mj12252 for ; Fri, 13 Dec 2002 18:05:49 +0100 (MET) Received: from davidb by opus.davidb.org with local (Exim 3.31 #1 (Debian)) id 18MtFI-0003CY-00; Fri, 13 Dec 2002 09:05:04 -0800 Date: Fri, 13 Dec 2002 09:05:04 -0800 From: David Brown To: Mike Potanin Cc: Brian Hurt , Blair Zajac , Caml Users Mailing List Subject: Re: [Caml-list] Resource acquisition is initialization Message-ID: <20021213170504.GA12278@opus.davidb.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, Dec 13, 2002 at 12:22:16PM +0300, Mike Potanin wrote: > > char * foo(...) { > > char buf[]; > > /* do something to fill buf */ > > return buf; > > } > > > > This sounds like a wonderful way to introduce dangling pointer bugs in the > > language. > Cyclone language handle this problec staticaly (compile time). It no need > GC use. Numerous languages handle this kind of construct. Often, though, you end up having to copy the result when you return. However, they wouldn't handle it if the function was defined to return a pointer. Instead, however, they let functions return larger objects (such as arrays). Usually they are implemented with a secondary stack to hold these values. I suspect, though, that the additional copying that ends up happening with the technique ends up being as, or more, expensive than Ocaml's garbage collector, especially if the data doesn't live long and doesn't survive the young area. Dave Brown ------------------- 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