Date: Sun, 21 Sep 1997 18:29:27 -0700 (PDT) From: Sean Eric Fagan <sef@Kithrup.COM> To: hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709220129.SAA24046@kithrup.com> In-Reply-To: <19970922015128.32876.kithrup.freebsd.hackers@bitbox.follo.net> References: <24205.874885838@time.cdrom.com>; from Jordan K. Hubbard on Sun, Sep 21, 1997 at 04:50:38PM -0700
next in thread | previous in thread | raw e-mail | index | archive | help
In article <19970922015128.32876.kithrup.freebsd.hackers@bitbox.follo.net> you write:
>On Sun, Sep 21, 1997 at 04:50:38PM -0700, Jordan K. Hubbard wrote:
>> > It doesn't. However, it has a formulation that IMHO is too
>> > restrictive - that free() 'makes the memory available for further use
>> > by the program' (from memory). Thus, an implementation of
>> Bizarre, are you sure? That's exactly 180 degrees counter to what
>> I've always learned about storage allocators: If you count on free()
>> to not corrupt the data you pass to it, you deserve to lose and lose
>> big.
>My typo. I mean 'further allocation'.
With either wording, eivind, fortunately, is wrong ;).
malloc() is constrained to not return the same memory block twice unless it
has been free()'d first.
ANSI C also makes no distinction between OS and standard library code --
that is, malloc() could be a system call, as far as ANSI C is concerned.
The requirement there is simply that free() makes the memory available for
further allocation (that being the only way an ANSI C conformant application
can get at such memory).
The wording for malloc() and free() was chosen very carefully, to allow
embedded applications to work -- in such applications, there is no dynamic
allocation of memory from the OS (since there isn't one); instead, many of
them have a chunk of memory that is part of the program's address space, and
malloc() and free() simply parcel it up.
Lastly, the wording for free() is, as I understood it when I last read it,
meant to convey the requirement that:
char *cp = malloc(100);
if (cp) {
free(cp);
cp = malloc(100);
}
always result in a non-NULL cp.
So, in conclusion: yes, the OS is perfectly free to have free() return the
memory back to the OS, even though traditional systems did not do this most
of the time. (It is a quality of implementation issue, and I think may be
referenced as such in the X3J11 notes/comments/explanation that are not
officially part of the standard.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709220129.SAA24046>