Date: Mon, 27 Mar 2006 12:57:51 -0800 From: Jason Evans <jasone@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Vasil Dimov <vd@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Proposed addition of malloc_size_np() Message-ID: <A66553DE-9518-4D29-9F63-10E2ED6F02D2@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A66553DE-9518-4D29-9F63-10E2ED6F02D2>