Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn) Newsgroups: net.lang.c Subject: Re: When does void make code less readable? Message-ID: <8982@brl-tgr.ARPA> Date: Wed, 6-Mar-85 10:42:15 EST Article-I.D.: brl-tgr.8982 Posted: Wed Mar 6 10:42:15 1985 Date-Received: Fri, 8-Mar-85 02:57:47 EST References: <1995@sun.uucp>, <2034@wateng.UUCP> <5086@utzoo.UUCP>, <8586@brl-tgr.ARPA> <5148@utzoo.UUCP> Organization: Ballistic Research Lab Lines: 27 Re: emalloc() etc. I also often package malloc() in routines like NodeAlloc() etc. that alloc the proper thing (e.g. a (struct node)) and perform the appropriate action when the malloc() fails. However, what the right action in this case really is, is dependent on the application. In production code, it is seldom appropriate to just print an error message and terminate the process. I built an interactive drawing system once that had to keep running in case of ANY foreseeable emergency, in order not to lose the user's hours of work when there was a system failure. In case of running out of memory, it set a flag which would cause display of an "out of memory" message at the appropriate time, and returned failure status from the allocator to its invoker so something sensible could be done to maintain the integrity of the linked data structures. Note that there was no "stderr" to print messages to (I had to arrange for messages to appear in the menu area of the refresh display list), and the message had to be deferred until the whole data structure had been processed, to avoid a cascade of error messages when one would do. I am not saying that such thorough error handling is ALWAYS required, but I would encourage program designers to think carefully about the handling of exceptional conditions wherever they may occur. I fear that providing an emalloc() in the standard library would mainly make it easier for programmers to excuse their not thinking about what to do in the error case. It wouldn't be any worse than not checking for malloc() failure, though. What we really need to do is to figure out some way to stamp out sloppy programming. Any ideas?