From owner-freebsd-current Sun Oct 20 20:59:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BB9737B404; Sun, 20 Oct 2002 20:59:56 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E29E743E42; Sun, 20 Oct 2002 20:59:50 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9L3xepk078946; Sun, 20 Oct 2002 21:59:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 20 Oct 2002 21:59:22 -0600 (MDT) Message-Id: <20021020.215922.59312540.imp@bsdimp.com> To: tlambert2@mindspring.com Cc: jake@locore.ca, ben@stuyts.nl, current@FreeBSD.ORG, jroberson@chesapeake.net, rwatson@FreeBSD.ORG, jeff@FreeBSD.ORG, alfred@FreeBSD.ORG Subject: Re: [Ugly PATCH] Again: panic kmem_malloc() From: "M. Warner Losh" In-Reply-To: <3DB36854.FFEC4E2F@mindspring.com> References: <3DB31925.7B70E70@mindspring.com> <20021020.155657.10475080.imp@bsdimp.com> <3DB36854.FFEC4E2F@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <3DB36854.FFEC4E2F@mindspring.com> Terry Lambert writes: : "M. Warner Losh" wrote: : > : > : + if (sops) : > : > : + free(sops, M_SEM); : > : > : > : > The kernel free() groks free(NULL, M_FOO), so the if isn't needed. : > : : > : Wow. That's bogus. It should panic. : > : > It isn't bogus. free(NULL) is defined to be OK in ansi-c. The kernel : > just mirrors that. : : The free(NULL) in ANSI C is to permit invocation of the garbage : collector; there are very specific semantics involved. Specifically, : if you do not call free(NULL), you are *guaranteed* that a malloc() : followed by a free() followed by a subsequent malloc(), if the size : of the area allocated by the subsequent malloc() is less than or : equal to the size of the area freed, *will not fail*. C99 just says: section 7.20.3.2: [#2] The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined. "If ptr is a null poter, no action occurs" doesn't sound like GC to me. Like I said, free(NULL) is well defined, and unambiguous, in ansi c 99. In fact, I see nothing in the final c99 spec that even comes close to what you are talking about. Maybe c89 did that (I'm too lazy to walk down stairs and find it), but it too is irrelevant as the base system moves towards c99 compliance. The rest is bogus too. free(NULL, M_FOO) is well defined in the kernel and does the right thing and likely isn't going to change. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message