From owner-freebsd-arch@FreeBSD.ORG Mon Mar 27 18:50:18 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 CE4A816A426; Mon, 27 Mar 2006 18:50:18 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 561F543D46; Mon, 27 Mar 2006 18:50:18 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gvs8kjs2lk8l0apa@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.4/8.13.3) with ESMTP id k2RIoHPp004926; Mon, 27 Mar 2006 10:50:17 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.4/8.13.3/Submit) id k2RIoHqS004925; Mon, 27 Mar 2006 10:50:17 -0800 (PST) (envelope-from jmg) Date: Mon, 27 Mar 2006 10:50:17 -0800 From: John-Mark Gurney To: Jason Evans Message-ID: <20060327185017.GF7001@funkthat.com> Mail-Followup-To: Jason Evans , John Baldwin , Vasil Dimov , Robert Watson , freebsd-arch@freebsd.org References: <44247DF1.8000002@FreeBSD.org> <20060326110929.V35431@fledge.watson.org> <4426D7A0.4040007@FreeBSD.org> <200603271110.02917.jhb@freebsd.org> <44281421.3060401@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44281421.3060401@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Vasil Dimov , Robert Watson , John Baldwin , 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 Reply-To: John-Mark Gurney 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 18:50:19 -0000 Jason Evans wrote this message on Mon, Mar 27, 2006 at 08:34 -0800: > John Baldwin wrote: > >On Sunday 26 March 2006 13:04, Jason Evans wrote: > > > >>Robert Watson wrote: > >> > >>>I wonder if the intuitive objection people are raising is actually with > >>>the name. Since malloc_size() is defined on at least one platform to > >>>return the requested size, maybe a name like malloc_allocated_size() (or > >>>something a bit more compact) would help avoid that confusion, and make > >>>it clear that the consumer is getting back a commitment and not a hint > >>>for future realloc(), etc. > >> > >>Maybe you're right. We could just call it malloc_usable_size() and be > >>compatible with Linux. > > > >It would help to know why such a function would be useful. :) Do you have > >a specific use-case? If the purpose is for a program to see that it really > >as Y >= X bytes when it did malloc(X) so that the program can use Y bytes, > >that would seem to only be a source of bugs and complexity. If the program > >wants Y bytes, it should malloc(Y). Many folks in the thread seem to think > >that this function would be used for a poor-man's realloc() wrapper or > >something, and I think such uses would be short-sighted at best. If there > >are other uses such as for having a debug malloc wrap the real one, then > >that might justify the API, but it is unclear what a useful use of this API > >would be. > > I can think of a few straightforward uses: [...] > 2) Suppose that we are using some sort of dynamically scalable data > structure, such as a hash table that we double in size every time > fullness crosses some threshold. In order to do that, we need to know > how large the table is. We can store that information, or we could just > query the size. (In this example, performance constraints might dictate > that we actually store the size of the table, but there are certainly > similar examples that wouldn't be so concerned with performance.) This use case is incorrect... a) you already have the size, since you have your hashing value around.. and b) you could end up with part of your has table uninitalized, say, alloc and initalize 24 bytes, the function returns 32, so you think, oh, well, bytes 25 through 32 are initalized, so I don't have to do anything.. This use case is correct if you used it as a poor man's realloc, where you allocated a block, then asked the size, but then, you may very well end up with a very bad hash value.. and in this case, you might as well realloc to this side.. > 4) Porting code from Linux. Case in point: Xara Xtreme, currently being > ported by Vasil Dimov. At the moment, he has to use dlmalloc. sad to say, but we seem to always inherit Linux's warts in the name of portability.. :( I'd say adopt a method similar to the ports tree, once we have 10+ ports depending upon it, then we can consider this.. but importing this function for a single program seems a bit excessive.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."