When does void make code less readable?
Henry Spencer
henry at utzoo.UUCP
Sun Mar 3 08:32:42 AEST 1985
> > 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
More information about the Comp.lang.c
mailing list