Re: [RFC] how to get the size of a malloc(9) block ?

On 11/29/13, 7:26 PM, Daniel Nebdal wrote:
> 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.
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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
>