From owner-freebsd-current Thu Aug 6 18:52:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA28914 for freebsd-current-outgoing; Thu, 6 Aug 1998 18:52:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA28851 for ; Thu, 6 Aug 1998 18:52:31 -0700 (PDT) (envelope-from reilly@zeta.org.au) Received: from zeta.org.au (d18.syd2.zeta.org.au [203.26.11.18]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id LAA32046 for ; Fri, 7 Aug 1998 11:52:08 +1000 Received: (qmail 10204 invoked by uid 1000); 7 Aug 1998 01:51:15 -0000 Message-ID: <19980807015115.10203.qmail@gurney.reilly.home> From: "Andrew Reilly" Date: Fri, 7 Aug 1998 11:51:15 +1000 (EST) Subject: Re: memory leaks in libc To: dg@root.com cc: bde@zeta.org.au, wollman@khavrinen.lcs.mit.edu, freebsd-current@FreeBSD.ORG In-Reply-To: <199808070142.SAA10235@implode.root.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman said: >>I always thought it odd that there were no implimentations of >>free() that were able to identify whether the pointer that they >>were passed was something that malloc had handed out previously. >>Surely malloc's data structures must have something to say about >>it. >> >>If free() could know this, then things like setenv could just go >>ahead and call free(), and if the previous object had not been >>malloc'ed then nothing would happen. > > If the string were malloced by the program (as opposed to the library), > then it won't be expecting setenv() to do a hidden free(). This could lead > to random memory corruption if the process modifies the freed memory. > In all of this dicussion, I can't stop thinking that the cure sounds far > worse than the disease. And yet it is a problem that I've never read a really good solution for. I read a comment on comp.lang.eiffel recently, about BeOS. Apparently they (the BeOS designers) have devised a protocol that goes by the name "wean/adopt", that is presumably about passing "ownership" of dynamically allocated objects around. Anyone know any details? Is it something that can be adopted here? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message