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>