Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!ima!ISM780B!jim From: jim@ISM780B.UUCP Newsgroups: net.lang.c Subject: Re: Re: When does void make code less re Message-ID: <151@ISM780B.UUCP> Date: Thu, 7-Mar-85 00:36:46 EST Article-I.D.: ISM780B.151 Posted: Thu Mar 7 00:36:46 1985 Date-Received: Fri, 8-Mar-85 03:29:07 EST Lines: 35 Nf-ID: #R:utzoo:-514800:ISM780B:25500115:000:2064 Nf-From: ISM780B!jim Mar 5 20:04:00 1985 >You've missed my whole point, Doug. The low-level routines are not >pre-empting the decision on how to handle errors, they are aiding in >the implementation of the most common decision: "on error, print a >message and die". By calling (say) emalloc rather than malloc, the >higher levels are signifying their decision to adopt this strategy, >and are asking the lower levels to handle the implementation. There >is no difference in power or flexibility, only in ease of use. Fine; so why aren't there e* versions of every routine that might possibly produce an error or call a routine that might produce an error? And why not have versions that write their messages in different languages and to different file descriptors? (These are rhetorical questions.) A special case like emalloc is just a wart, making clear the absence of a decent global strategy. I think catch/throw is the best, but even the PWB fatal package or the USG matherr approach makes for far far better software engineering than emalloc. The existence of emalloc just encourages you to write a subroutine that calls it, but I can't call your routine because you have preempted the error policy decision. >Note my earlier comment about the usefulness of a global s/malloc/emalloc/ >in Berkeley code. By requiring the caller to do the work of checking >for success, even when there is nothing meaningful to be done about >failure, the bare malloc interface encourages sloppy programmers to >ignore the whole issue. It also makes conscientious programmers do >repetitive and annoying extra work. You have made a common error: the existence of a problem is in no way a justification for any specific solution (this applies well to "initialize first member" too). The key problem is that the current default action when malloc fails is a core dump or other random behavior. I would argue that the right solution is to make the default be an error message and exit, but to allow that behavior to be modified, which emalloc does not allow. -- Jim Balter, INTERACTIVE Systems (ima!jim)