Re: Proposed addition of malloc_size_np()

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."
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"