On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff <glebius_at_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. -- Daniel NebdalReceived on Fri Nov 29 2013 - 10:26:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC