Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!eecae!netnews.upenn.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: return value of free
Message-ID: <9524@smoke.BRL.MIL>
Date: 28 Jan 89 04:11:54 GMT
References: <287@proton.UUCP> <1849@dataio.Data-IO.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 35

In article <1849@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
>I intend to leave it this way, and in stdlib.h have something like:
>	#if __STDC__
>	void
>	#else
>	int
>	#endif
>		free(void *);

But this is wrong, except perhaps for Zortech C.  free() traditionally
never did return a value, although before "void" was added to C there
was no way to express this.

Note that none of the standard C library routines are specified with
provisions for indicating programmer usage errors.  This does not mean
that defensive programming is bad, merely that the burden for safety
checking was deemed better taken on explicitly by applications than by
the standard library.  For example, you could implement your own "safe"
alloc/dealloc routines as wrappers around malloc()/free().  In fact we
have done that for a large programming project I'm currently involved
with.  This technique has the advantage that time-consuming exhaustive
validation can be performed under optional debugging control, and when
a usage error is detected the error handling can be just what we want
it to be (we also have a special package for logging errors).  For such
a thorough job of usage validation, anything extra done in the standard
library would be a total waste of time.

For less careful applications, cheap tests for null pointers, etc. can
and probably should be done in the implementation of the standard
library.  Better to get an assert() failure during development than to
have the code run amok in unpredictable ways during production use.
But I don't think the standard library is any place to implement more
thorough safety checks.  Applications that want them will provide their
own, and know that their availability will not depend on the whims of
the C implementors.