From owner-freebsd-hackers Sun Sep 21 22:41:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA14744 for hackers-outgoing; Sun, 21 Sep 1997 22:41:21 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA14735 for ; Sun, 21 Sep 1997 22:41:17 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id HAA08860; Mon, 22 Sep 1997 07:40:15 +0200 (CEST) To: "Jordan K. Hubbard" cc: Eivind Eklund , Nate Williams , Eivind Eklund , hackers@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Sun, 21 Sep 1997 16:50:38 PDT." <24205.874885838@time.cdrom.com> Date: Mon, 22 Sep 1997 07:40:15 +0200 Message-ID: <8858.874906815@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <24205.874885838@time.cdrom.com>, "Jordan K. Hubbard" writes: >> 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. Look, it's really very simple. In other text it says that you cannot know what's in the storage you get with malloc, so the only way to know if you got the same storage back would be to compare the pointer. Second, I think the above wording is intended to avoid implementations of this kind: static u_char *malloc_ptr = end; void * malloc(int n) { void *p; p = malloc_ptr; malloc_ptr += n; return p; } void free(void *) { } -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."