From owner-freebsd-arch@FreeBSD.ORG  Sat Mar 25 19:11:34 2006
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 7C4DE16A420
	for <freebsd-arch@FreeBSD.org>; Sat, 25 Mar 2006 19:11:34 +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 D721843D53
	for <freebsd-arch@FreeBSD.org>; Sat, 25 Mar 2006 19:11:33 +0000 (GMT)
	(envelope-from jasone@FreeBSD.org)
Received: by lh.synack.net (Postfix, from userid 100)
	id 9D77C5E4912; Sat, 25 Mar 2006 11:11:33 -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 420855E48F1;
	Sat, 25 Mar 2006 11:11:32 -0800 (PST)
Message-ID: <442595E2.5080804@FreeBSD.org>
Date: Sat, 25 Mar 2006 11:11:30 -0800
From: Jason Evans <jasone@FreeBSD.org>
User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
References: <44247DF1.8000002@FreeBSD.org>	<200603250806.k2P86YJU011861@apollo.backplane.com>	<4424FDE9.3080707@FreeBSD.org>
	<20060325185612.GC7001@funkthat.com>
In-Reply-To: <20060325185612.GC7001@funkthat.com>
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: 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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Mar 2006 19:11:34 -0000

John-Mark Gurney wrote:
> Jason Evans wrote this message on Sat, Mar 25, 2006 at 00:23 -0800:
> 
>>have to store the precise allocation request size; it can instead round 
>>the request size up internally, then treat the allocation as being of 
>>this rounded up size.  By vaguely specifying the return value of 
>>malloc_size_np(), we grant the malloc implementation freedom as to 
>>whether the size is precisely what was specified during allocation, or 
>>some rounded up value.
>>
>>I had no intention of suggesting that malloc_size_np() should extend 
>>existing allocations, nor change the return value depending on the 
>>current state of memory following the allocation pointed to by ptr.
> 
> Ok, so what you are saying is that the function returns the size of
> the bucket (if any) that the memory was allocated from...  But even
> though this function may return a larger value, the program is not
> allowed to use extra space, and it's only useful for further
> allocations of the same size?

I'm saying that malloc_size_np() returns the size of the allocation, to 
the best of the allocator's knowledge.  If you malloc(17), and 
malloc_size_np() returns 32 for that allocation, then you can treat it 
as a 32-byte allocation.  However, the malloc implementation could 
conceivably return any value >=17.

Jason