Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: When does void make code less readable? Message-ID: <5148@utzoo.UUCP> Date: Sat, 2-Mar-85 17:32:42 EST Article-I.D.: utzoo.5148 Posted: Sat Mar 2 17:32:42 1985 Date-Received: Sat, 2-Mar-85 17:32:42 EST References: <1995@sun.uucp>, <2034@wateng.UUCP> <5086@utzoo.UUCP>, <8586@brl-tgr.ARPA> Organization: U of Toronto Zoology Lines: 39 > > One thing which *can* be very handy is variants of the standard routines > > which are "guaranteed" to work because they abort the program if the > > standard routine underneath returned an error. > > I much prefer to have a low-level routine return an indication to its > invoker when it cannot do its function for whatever reason. Strategy > should be managed at higher levels. 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. As somebody (John Mashey?) once said: If you want people to follow a standard, it must be easier to be standard than to be non-standard. 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. Of course, we need the bare interface: sometimes there *is* meaningful action to be taken in the event of failure. But usually, the only thing to do is complain and die. It makes all kinds of sense to package this common case in a form that makes it easy to use, so that people will do it right. It also makes a remarkable difference in ease of use if a program is doing mallocs all over the place; the difference is marked enough to inspire the "why didn't we put that in the library long ago?" feeling that marks a good library routine. Try it, you'll like it. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry