Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pilchuck!dataio!fnx!nazgul!bright
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: why is free() a void?
Message-ID: <130@nazgul.UUCP>
Date: 31 Oct 90 10:42:53 GMT
References: <1749@meaddata.meaddata.com>
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle
Lines: 25

In article <1749@meaddata.meaddata.com> rob@pmserv.meaddata.com writes:
<As the subject says, I'm curious as to why free() does not return a value.
<It seems to me that it could pass back some useful information, especially
<if there was a problem.  Was the pointer NULL, or an invalid address??
<Was the memory not allocated by malloc() or it's siblings??

I used to feel that free() should return a value, basically indicating if
malloc's data structures were corrupted or not. After using this for years,
it became clear that the only reasonable thing to do is to abort the
program:
	if (free(p))
		abortprogram("heap is corrupted");
If the data structures are corrupted, it is best to terminate the program
as soon as possible, to avoid doing terrible things like corrupting DOS
or the FAT. Thus, it became apparent that the abort should be moved inside
of free(). That's what the Zortech free function does now, if it detects
a corrupted heap it prints the message:
	"Heap is corrupted"
and immediately terminates the program. free() now returns a void.

Occaisionally someone wants to regain control after this, so they can
'fail gracefully'. My argument is that if the heap is corrupted, the
program has already failed gracelessly, and it's best to terminate
it before more goes wrong. (The library source is available for
the diehards anyway!)