From owner-freebsd-arch@FreeBSD.ORG Tue Mar 28 09:11:59 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9ABE16A401; Tue, 28 Mar 2006 09:11:59 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail22.syd.optusnet.com.au (mail22.syd.optusnet.com.au [211.29.133.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBAAD43D48; Tue, 28 Mar 2006 09:11:58 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail22.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k2S9BrwK000747 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 28 Mar 2006 20:11:56 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k2S9Br7W002164; Tue, 28 Mar 2006 20:11:53 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k2S9Brg2002163; Tue, 28 Mar 2006 20:11:53 +1100 (EST) (envelope-from peter) Date: Tue, 28 Mar 2006 20:11:53 +1100 From: Peter Jeremy To: Jason Evans Message-ID: <20060328091153.GC961@turion.vk2pj.dyndns.org> References: <44247DF1.8000002@FreeBSD.org> <20060326110929.V35431@fledge.watson.org> <4426D7A0.4040007@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> <44281421.3060401@FreeBSD.org> <20060327185017.GF7001@funkthat.com> <352D1430-CC72-47EE-9E50-B1C4404ACA95@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <352D1430-CC72-47EE-9E50-B1C4404ACA95@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-arch@freebsd.org Subject: Re: Proposed addition of malloc_size_np() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 09:11:59 -0000 On Mon, 2006-Mar-27 12:52:17 -0800, Jason Evans wrote: >void * >malloc(size_t size); > >void * >calloc(size_t size); > >void * >realloc(void *ptr, size_t size, size_t old_size); > >void >free(void *ptr, size_t size); ISTR AmigaDOS did something like this (my autodocs are packed away somewhere so I can't quickly check). The downside is that you have to keep the malloc() size stashed away so you can pass it to free(). This could be problematic where a function returns malloc'd memory (eg asprintf(), strdup()). It also fails to solve the leak from: ptr = realloc(ptr, NEW_SIZE); where realloc() returns NULL. In an ideal world, a pointer would be an [address, size] pair (or even [size, address, type] tuple) so that any the bounds (and type) can be verified by anything that wants to. (The iAPX432 tried this). I think we've got even less chance of re-designing C than re-designing malloc (and C++ can't do this because you can't override builtin types). >breaking compatibility. Let's re-visit Poul-Henning's suggestion, >which involves a parallel API that exposes the internal sizes to the >application. The following is not identical to what he proposed, but >it has the same semantics: > >void * >malloc_np(size_t *size); > >void * >calloc_np(size_t *size); > >void * >realloc_np(void *ptr, size_t *size, size_t *old_size); > >void * >memalign_np(size_t alignment, size_t *size); > >void * >free_np(void *ptr, size_t *size); A try_realloc() function would be nice - where you can determine whether the realloc succeeded or not (or maybe how much memory it could obtain) without accidently leaking the old region if the realloc() failed. >[1] In a slightly more ideal world, we would add malloc_size() >instead of malloc_usable_size(), which would return the size that was >passed to malloc()/calloc()/realloc(). However, that would impose >implementation constraints on the allocator that would have far- >reaching implications. I don't want to get into the details here, >but suffice it to say that requiring support for malloc_size() would >require a lot of extra space overhead for many allocator designs, >including for phkmalloc and jemalloc. If you really want to detect off-by-one errors, realloc() and free() need to know exactly how many bytes were asked for so they can verify that the immediately following byte still has the magic value that malloc/realloc wrote there. (Admittedly, this is for debugging only). -- Peter Jeremy