From owner-freebsd-arch@FreeBSD.ORG Sat Mar 25 08:37:33 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 BF8D416A400; Sat, 25 Mar 2006 08:37:33 +0000 (UTC) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE73D43D48; Sat, 25 Mar 2006 08:37:29 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 9D1AD1A3C22; Sat, 25 Mar 2006 00:37:29 -0800 (PST) Date: Sat, 25 Mar 2006 09:37:29 +0100 From: Maxime Henrion To: Jason Evans Message-ID: <20060325083729.GN80618@elvis.mu.org> References: <44247DF1.8000002@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44247DF1.8000002@FreeBSD.org> User-Agent: Mutt/1.4.2.1i 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: Sat, 25 Mar 2006 08:37:33 -0000 Jason Evans wrote: > === Proposal === > Add malloc_size_np() to libc, and provide the prototype in malloc_np.h: > > size_t > malloc_size_np(const void *ptr); > > This function would return the usable size of the allocation pointed to > by ptr, which is always greater than or equal to the size that was > specified in the call to malloc(), calloc(), posix_memalign(), or > realloc(), regardless of allocator implementation. It is up to the > implementation whether the value returned by malloc_size_np() differs > from the size specified during allocation, but the return value must be > consistent across multiple calls for the same allocation. > > === Rationale === > The standard malloc(3) API does not provide a mechanism for querying the > sizes of existing allocations. This can be useful for a variety of > purposes, including introspection and putting wrappers around the system > malloc implementation. For a stand-alone application, it is possible to > always keep track of allocation sizes, but when integrating with third > party libraries, this may not be possible. > > The lack of such a function causes issues when porting software from > Linux or OS X. Linux provides malloc_usable_size(), which returns the > usable size of an allocation (may be larger than the allocation request > size). OS X provides malloc_size() and malloc_good_size(), which return > the precise allocation request size and the usable size of the > allocation, respectively. By providing malloc_size_np(), we provide an > analogue to these APIs, without placing undue constraints on future > malloc implementations. > > I propose malloc_size_np() rather than malloc_size() (and a separate > header file) in order to emphasize the non-portability of this function. > As a case in point, the proposed semantics differ from those of OS X's > malloc_size(). If we were to use malloc_size(), there would be the > potential for undue expectation of equivalence between operating systems. > > === I like this idea and, for one, can't see anything to change in your proposal :-). Cheers, MAxime