From owner-freebsd-arch@FreeBSD.ORG Mon Mar 27 20:57:02 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 203FF16A401; Mon, 27 Mar 2006 20:57:02 +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 D965843D69; Mon, 27 Mar 2006 20:57:00 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id C27065E48D7; Mon, 27 Mar 2006 12:57:00 -0800 (PST) Received: from [129.101.167.145] (unknown [129.101.167.145]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 1DADE5E48D7; Mon, 27 Mar 2006 12:57:00 -0800 (PST) In-Reply-To: <200603271520.11381.jhb@freebsd.org> References: <44247DF1.8000002@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> <44281421.3060401@FreeBSD.org> <200603271520.11381.jhb@freebsd.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Mon, 27 Mar 2006 12:57:51 -0800 To: John Baldwin X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.5 (2005-11-28) on lh.synack.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.5 Cc: Vasil Dimov , Robert Watson , 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: Mon, 27 Mar 2006 20:57:02 -0000 On Mar 27, 2006, at 12:20 PM, John Baldwin wrote: > On Monday 27 March 2006 11:34, Jason Evans wrote: >> I can think of a few straightforward uses: >> >> 1) Suppose that we are about to write to a string that we know is >> malloc()ed, and we want to be sure that we aren't overflowing the >> allocated buffer. We can add an assertion that the buffer is indeed >> large enough to contain what is about to be written to it. > > In that case though you really want to know the size you allocated, > not necessarily the backing-store size, esp. if you are in a library > since your caller may (correctly) assume that if it allocates X > bytes for a string the library will only write up to X bytes. So, I > think in that case you want the requested size, not the backing store > size. Yes, you're right that we actually want the requested size rather than the backing-store size. This is only a "better than nothing" use case. >> 4) Porting code from Linux. Case in point: Xara Xtreme, currently >> being >> ported by Vasil Dimov. At the moment, he has to use dlmalloc. > > Does it contain a G/C of its own or some such? I don't know the answer to that. >> Following is what I've written for the malloc(3) man page: >> ---- >> The malloc_usable_size() function returns the usable size of the >> allocation pointed to by ptr. The return value may be larger than >> the >> size that was requested during allocation. malloc_usable_size() >> is not >> intended as a mechanism for in-place realloc(), though it can be >> abused >> that way; rather it is primarily provided as a tool for introspection >> purposes. Any discrepancy between the requested allocation size >> and the >> size reported by malloc_usable_size() should not be depended on, >> since >> such behavior is entirely implementation-dependent. >> ---- > > I would word it stronger: "malloc_usable_size() should not be used > as a > mechanism for in-place realloc(). It is provided solely as a tool for > introspection purposes." Okay, sounds fine to me. Thanks, Jason