Date: Fri, 29 Nov 2013 19:49:06 +0800 From: Julian Elischer <julian@freebsd.org> To: Daniel Nebdal <dnebdal@gmail.com>, Gleb Smirnoff <glebius@freebsd.org> Cc: Current <freebsd-current@freebsd.org>, jb <jb.1234abcd@gmail.com> Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <52987F32.1010500@freebsd.org> In-Reply-To: <CA%2Bt49PJZ5TJ35SBYWT3i46jwfPN%2B3hV-ap-X5fDUg6NKgLxiNg@mail.gmail.com> References: <CA%2BhQ2%2BiNurBQnmH-4-DN9V-krc_R=dbEaznJkxLDOzkJEWpFMg@mail.gmail.com> <loom.20131128T143120-188@post.gmane.org> <20131128140637.GA62346@onelab2.iet.unipi.it> <loom.20131128T161159-463@post.gmane.org> <20131129105959.GF90895@FreeBSD.org> <CA%2Bt49PJZ5TJ35SBYWT3i46jwfPN%2B3hV-ap-X5fDUg6NKgLxiNg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/29/13, 7:26 PM, Daniel Nebdal wrote: > On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff <glebius@freebsd.org> wrote: > >> On Thu, Nov 28, 2013 at 03:13:53PM +0000, jb wrote: >> j> > But I don't understand why you find ksize()/malloc_usable_size() >> dangerous. >> j> > ... >> j> >> j> The original crime is commited when *usable size* (an implementation >> detail) >> j> is exported (leaked) to the caller. >> j> To be blunt, when a caller requests memory of certain size, and its >> request is >> j> satisfied, then it is not its business to learn details beyond that >> (and they >> j> should not be offered as well). >> j> The API should be sanitized, in kernel and user space. >> j> Otherwise, all kind of charlatans will try to play hair-raising games >> with it. >> j> If the caller wants to track the *requested size* programmatically, it >> is its >> j> business to do it and it can be done very easily. >> >> +1 >> >> This is kind of APIs that just shouldn't exist. >> >> -- >> Totus tuus, Glebius. >> > > Then again: Using the "overflow" memory is only going to bite them if the > API lies : If the return value is exactly "the size of the block you got > allocated and can safely use until you free it", using it will per > definition be safe. If the allocator later changes to, say, always > allocate exact byte ranges, or to allocating blocks but having the option > to fragment them later - then the return value would have to shrink to > match, and any program using it would still DTRT. > > I'm completely ambivalent about adding it, though - it's not something I > need, it's more stuff that needs to be handled if you change/rewrite the > allocator, and it's not my decision. I think that if you want to play games with expanding buffers etc, then you should write your own allocator. You asked for X bytes. you should expect that you get X bytes and nothing more... either that or you should have asked for more in the first place. > > -- > Daniel Nebdal > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52987F32.1010500>