Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: Making C a little more 'foolproof' (was Re: Naming)
Message-ID: <16077@haddock.ima.isc.com>
Date: 3 Mar 90 01:13:37 GMT
References: <MCDANIEL.90Feb20172440@orenda.amara.uucp> <1990Feb23.184656.3110@siia.mv.com> <16021@haddock.ima.isc.com> <MCDANIEL.90Feb27103 <681@mwtech.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 57

In article <681@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>In article <12246@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>>It would be better to use some name other than malloc for this macro.
>
>Yes and No - it depends on why I (or the poster) want to do this.
>
>[C requires the user to do error checking; Pascal simply aborts on failure.]
>This often has lead to the general assumption [that C is 'unsafe'],
>but it's very seldom noticed, that it takes NOT MORE THAN 1 (ONE)
>HEADER-FILE and a few additions to the library, to rectify most of it.

I agree that it can be useful to have an error-handling version of malloc(),
but I agree with Doug that it should be called by a different name.
*Especially* if you're teaching a course!  How are your students supposed to
learn that there's a difference between standard malloc() and your local
"improved" version?

Side note: error handling is a botch in ANSI C; this was recognized by the
Committee.  There was no prior art that could be used to build a reasonable
facility, and it was against the Charter to invent one from scratch, so they
kept the system that Unix uses.  As with other such situations, there's room
for it to be fixed in the *next* standardization, if a good system is invented
and tested in the meantime.  With that in mind...

>But you can make this scheme more sophisticated and usable for production
>programming. You only need to call the error handlers from the "s"-functions
>via function pointers, that can be altered from outside (but should default
>to diagnostic messages and/or termination).

Alternately, an implementation could provide these error-handling features in
the actual library routines rather than in "s"-functions.  The default action
would have to be "ignore" (to retain compatibility with the current Standard),
but there could be a simple way for the user to globally change this default.

I don't much like using signal-like semantics, since it often means you have
to use a messy longjmp() to recover.  Another possibility is that when "safe
mode" is enabled, routines continue to indicate errors quietly (i.e. by
setting an internal flag which replaces errno), but only if no error is
already pending.  A routine iserror() would test and clear the internal flag.
Thus, instead of
	if ((vp = malloc(siz)) == NULL) die();
one would write
	vp = malloc(siz);
	if (iserror()) die();
, and instead of
	(void)remove(tmpfile); /* okay if file already gone */
one would write
	remove(tmpfile);
	(void)iserror();
Unlike errno, there would be no risk that the error flag is "old".  It would
never be set by a successful routine, and one may not invoke any "unsafe"
routine (i.e. a function that might set the flag) while it is set.  Doing so
would cause the program to abort with a signal.

Any other ideas?

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint