From owner-freebsd-arch@FreeBSD.ORG Fri Mar 24 23:17:10 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 6E81616A423 for ; Fri, 24 Mar 2006 23:17:10 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D5F943D68 for ; Fri, 24 Mar 2006 23:17:07 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id 82DB95E48BF; Fri, 24 Mar 2006 15:17:07 -0800 (PST) Received: from [192.168.168.201] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 2F29B5E48BF for ; Fri, 24 Mar 2006 15:17:06 -0800 (PST) Message-ID: <44247DF1.8000002@FreeBSD.org> Date: Fri, 24 Mar 2006 15:17:05 -0800 From: Jason Evans User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.5 (2005-11-28) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.5 Cc: Subject: 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: Fri, 24 Mar 2006 23:17:10 -0000 === 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. === Comments? Thanks, Jason