From mboxrd@z Thu Jan 1 00:00:00 1970 From: Einar Karttunen To: 9fans@cse.psu.edu Subject: Re: [9fans] making emalloc a library function Message-ID: <20040307172511.GA31935@melkki.cs.Helsinki.FI> References: <8ba1956a9b92658e6e3c216f3cc5b3cc@plan9.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Date: Sun, 7 Mar 2004 19:25:11 +0200 Topicbox-Message-UUID: 1f0c24b2-eacd-11e9-9e20-41e7f4b1d025 On 07.03 09:06, Rob Pike wrote: > right. my main objection is that the specification of what to do in the > case of errors is so application-dependent that making a library for it > will either fail to capture many cases or encourage programs to fail > poorly. Well it seems that many programs in the source tree want the same behaviour as it is. And no-one would be forced to use the library. The functions lib9p seem to do this (at least close). Would it be possible to start from there? > plus, i mean really, how hard is emalloc to write? the part you'd > put in a library is trivial. the part that matters is still up to you. So why are part of the emalloc implementations missing e.g. setmalloctag? Of course it is quite trivial to write, but in my opinion having dozens of definitions for the same function is not exactly sane. Also if one writes a malloc wrapper which behaves unlike the emallocs naming it emalloc is quite confusing. - Einar Karttunen