osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (09/05/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Thu, 5 Sep 85 Volume 10 : Issue 1
Today's Topics:
free (2 msgs)
malloc (2 msgs)
malloc and free (2 msgs)
----------------------------------------------------------------------
Date: Thu, 22 Aug 85 09:13:47 edt
From: allegra!phri!roy (Roy Smith)
Subject: free
To: allegra!cbosgd!std-c
In V9#5, Guy Harris <sun!guy> says:
> Handing it [free()] anything other than a pointer obtained through
> "malloc" is an error. The behavior ... should be left unspecified.
> The implementor should not be constrained by having to make the code
> do something "nice" when used improperly.
Can't you have some external flag (say, _Free_Widget) controlling
what free does in this situation? It's initialized to 1 in free.c; when
free() gets an invalid pointer, it looks at the value in _Free_Widget. If
it is still 1, free() dumps core. If the user has reset it, free() just
returns some error status.
Thus, you have it both ways. The typical programmer gets some
added protection against a very insidious bug. For those who actually
*want* to be able to pass free a null pointer, it's trivial to turn off the
checking.
Possibly this idea could be extended to other library functions,
but I'm not sure that widening the interface between a user's code and a
library is always a good idea. For example, accidentally trashing one of
these fine-tuning parameters could in itself lead to all sorts of hard to
find bugs.
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: Wed, 21 Aug 85 13:31:02 EDT
From: seismo!elsie!ado
Subject: free
To: hou2d!osd
These earlier words of mine:
> > Many (most?) existing systems die if free is passed NULL.
> > So let's mandate that free() MUST DIE if passed NULL.
> > This will discourage folks from passing NULL to free,
> > and will therefore encourage the development of more portable code.
prompted comments that I'd like to in turn comment on.
> . . .free() should just return gracefully, after doing nothing.
Maybe that's what free() "should" do; alas, it isn't what free actually does.
And having a standard that fails to tell the truth is worse than not
having a standard. Of course, if the standard writers want to invent a new
function, for example
void dealloc(p) void * p; { if (p != 0) free(p); }
then it's fine to say that "dealloc does nothing if passed NULL."
> In general, don't make it easier for the user to dump core!!
Having a standard that says "free does nothing if passed NULL" WILL make it
easier for the user to dump core--the dump will happen any time something is
developed on a "standard" system and shipped to ANY system running current
software.
> Discourage unportable code using other methods.
I'm eager to hear suggestions for "other methods."
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
------------------------------
Date: Fri, 30 Aug 85 18:43:24 EST
From: john@basser.oz
Subject: malloc
To: std-c@cbosgd
In article <642@hou2d.UUCP> ihnp4!arizona!wendt (Alan Wendt) writes:
> The argument *for* is consistency: if we can allocate an array
> containing one element, we ought to be able to allocate zero elements.
>
> The argument *against* is utility: Such a call is very likely to
> arise out of a fencepost error. Since it doesn't accomplish anything,
> why not just disallow it and abort, instead of dying horribly later
> on ...
To hell with ``utility'', consistency is FAR more desirable. It is
not possible to say that a call to malloc(0) "doesn't accomplish anything".
I have seen a program which deliberately makes calls to malloc(0),
in order to obtain pointers that may be used in calls to realloc
later on. Why stop people doing things? Sooner or later someone
will think of an application for what you stopped them doing.
John Mackin, Basser Department of Computer Science,
University of Sydney, Sydney, Australia
------------------------------
Date: Sat, 24 Aug 85 00:13:09 -0100
From: seismo!mcvax!root44!addw
Subject: malloc
To: ihnp4!houxm!hou2d!osd
>> From: ihnp4!arizona!wendt (Alan Wendt)
>> Subject: malloc(0)
>> Another area of memory allocation (besides free((void *)0) that
>> needs to be specified is whether or not malloc(0) is legal.
I would like to see this work. The main reason is that it would make some
if-first-time code not needed. This is where you allocate some memory, then
expand it with realloc as you need more.
This relates to something that I seem to remember seeing in a proposed
standard: realloc() is NOT guaranteed to preserve the contents of the area
that you give it. What is the point of realloc() if it doesn't do this?
Is my memory at fault, or is this another case of the 'standard being a
catalogue of the bugs in current implementations'?
Alain Williams,
Root Computers Ltd, London, England.
<UK-net>!{hrc63|qmc-cs|edai|kcl-cs|ukc|glasgow|ist|jmccfr|west44
ubu|rlvd|pmllab|stc}!root44!addw
{unisoft|deccra}!root44!addw
root44!{rootcl|rootis}!addw
------------------------------
Date: Thu, 22 Aug 85 17:28:50 edt
From: pegasus!hansen
Subject: malloc and free
To: std-c@cbosgd
< From: sun!guy (Guy Harris)
< I agree that "free" should not be mandated to drop core if handed a null
< pointer. I disagree that it should be mandated to return gracefully.
< *** Handing it anything other than a pointer obtained through "malloc" is an
< error.*** The behavior of "free" when handed such an object should be left
< unspecified. The implementor should not be constrained by having to make
< the code do something "nice" when used improperly.
<
It can be argued that free() ought to be able to accept ALL pointers that
malloc() can return, including the NULL pointer.
Tony Hansen
ihnp4!pegasus!hansen
------------------------------
Date: Thu, 22 Aug 85 11:40:59 mdt
From: ihnp4!alberta!myrias!cg (Chris Gray)
Subject: malloc and free
To: alberta!ihnp4!cbosgd!std-c
On the subject of malloc and free handling bad data.
Most uses of malloc and free are such that bad parameters to either are
a bug, and the programmer would like a core dump. SOME uses, however,
may be of the form "is this a valid thing to do?". In the case of
malloc, what should it do if it can't satisfy a legitimate request? Returning
-1 or NULL can be unfriendly, especially if the program doesn't use the
returned value right away, but instead saves it away somewhere for use at
a (possibly much) later time. Thus, the error return codes from malloc
and free are often quite necessary. The solution is quite simple - have the
bottom level routines return an error condition. The user can then write
trivial interface routines which core dump if the lower-level ones indicate
an error. These routines should probably first print (on stderr) a message
of the form "prog: malloc failed". For the lazy majority, the standard
library can include standard variants which just print "malloc failed" or
"free failed" and quit with a core dump.
Chris Gray ihnp4!alberta!myrias!cg
------------------------------
End of mod.std.c Digest - Thu, 5 Sep 85 08:10:44 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.