From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <033601c4047b$e102c480$67844051@SOMA>
From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
References: <8ba1956a9b92658e6e3c216f3cc5b3cc@plan9.ucalgary.ca> <BCDC69A4-7059-11D8-8891-000A95B984D8@mightycheese.com>
Subject: Re: [9fans] making emalloc a library function
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Date: Sun,  7 Mar 2004 20:39:16 +0100
Topicbox-Message-UUID: 1f59a958-eacd-11e9-9e20-41e7f4b1d025

> 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.

exactly, unless you add yet another two arguments (which i'd be
loathed to do):

   - function to call on failure
   - arg to function

but i'd guess that this would degenerate to:

    - exits
    - "ran out of memory"

so i'd be against it.

malloc failing is not always fatal.