From owner-freebsd-hackers Sun Sep 21 23:09:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA16917 for hackers-outgoing; Sun, 21 Sep 1997 23:09:46 -0700 (PDT) Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16909 for ; Sun, 21 Sep 1997 23:09:43 -0700 (PDT) Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id XAA15857; Sun, 21 Sep 1997 23:09:38 -0700 (MST) From: Terry Lambert Message-Id: <199709220609.XAA15857@usr07.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: ac199@hwcn.org Date: Mon, 22 Sep 1997 06:09:37 +0000 (GMT) Cc: sef@kithrup.com, hackers@FreeBSD.ORG In-Reply-To: from "Tim Vanderhoek" at Sep 21, 97 10:35:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > No, if you want the above code to always result in a non-NULL cp, > free() cannot ever return the memory back to the OS. ...with the caveat that the OS is a memory overcommit OS, such that the next call may fail because of another process. > However, I believe the actual wording is sufficiently ambigous that > this debate has been fought long and hard in other forums. Including this one, about 7 months ago... > Anything which is this controversial can be implemented either way > and be right. > > Besides, there ain't no standard which can tell me that free() can't > return memory to the OS. Wrong. Technically, the reallocation does not have to check its return value, and may assume the allocation never fails, according to the standard. The question to ask of the code is whether it *needs* the memory, or merely *wants* the memory. If it merely *wants* the memory, then a failed allocation is a recoverable condition, since it checks the return value of the function. If you want to be entirely technical about it, a malloc only has to return a pointer that becomes valid when used. That means that it can return a pointer to an unmapped page, and map the page in when the allocated area is actually written (or read -- though that's not too useful). The allocation of backing store for the allocated region could fail at that time, as well, technically. So a malloc can return a non-failure indicator, yet have failed. Ah, the mysteries of memory overcommit! 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.