Dealing with naive malloc() implementations

[Christopher Benson-Manica]

Some recent posts got me thinking about how one might have dealt with
simplistic malloc() implementations which might return NULL for a 64K
request but might accept two 32K requests or four 16K requests. (I'm
assuming, perhaps incorrectly, that quality modern implementations
will coalesce free space as necessary and if possible to satisfy
requests.) I came up with the following (compilable but untested)
first cut at code to try a combination of smaller allocations:

#include <stdlib.h>
#define MAX_SUBCHUNKS 4

/* Functions for accessing individual chunk members omitted */

struct chunk {
void *data[MAX_SUBCHUNKS];
int num_subchunks;
/* Needed by chunk accessors to correctly calculate which subchunk a
* requested member will be in, given that the division of members
* in subchunks is done in a known way, as below */
size_t nmemb;
size_t size;
};

struct chunk *allocate_chunk( struct chunk *chunk, size_t nmemb, size_t size ) {
size_t idx, jdx;
int succeeded;
chunk->nmemb=nmemb;
chunk->size=size;
for( idx=0; idx < MAX_SUBCHUNKS; idx++ ) {
chunk->num_subchunks=idx+1;
succeeded=1;
for( jdx=0; jdx < idx; jdx++ ) {
size_t num_members=nmemb/(idx+1)+( nmemb%(idx+1)>jdx ? 1 : 0 );
if( (chunk->data[jdx]=malloc(num_members)) == NULL ) {
succeeded=0;
break;
}
}
if( !succeeded ) { /* One of the suballocations failed - free all
existing allocated space */
for( jdx=0; jdx < idx; jdx++ ) {
if( chunk->data[jdx] != NULL ) {
free( chunk->data[jdx] );
}
else {
break;
}
}
continue; /* Try again with more subchunks */
}
return chunk;
}
return NULL; /* Couldn't allocate memory in any combination of
subchunks */
}

int main(void) {
return 0;
}

Were (are?) there implementations where this strategy (or something
along the same lines but undoubtedly more sophisticated) might have
been required to work around a malloc() that was too silly to work out
the details for itself?

This question gives rise to another point - a function that allows the
user to query the malloc() implementation and determine the maximum
number of objects with a given size that it will accept an allocation
request for would really be handy. I wouldn't think that such a
function would be difficult for the malloc() implementor to provide,
assuming that the caller accepts the obvious performance penalty.
This would allow code that needs a substantial but arbitrary amount of
space to easily ask malloc(), "How much space can I have? Ok, that's
enough, give me all of it." Was such a function considered? (I can
take this followup question to comp.std.c if need be.)

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Christopher Benson-Manica]

Christopher Benson-Manica <at***@faeroes.freeshell.orgwrote:

(a rather lengthy post)

struct chunk *allocate_chunk( struct chunk *chunk, size_t nmemb, size_t size ) {

(snip)

for( jdx=0; jdx < idx; jdx++ ) {
size_t num_members=nmemb/(idx+1)+( nmemb%(idx+1)>jdx ? 1 : 0 );
if( (chunk->data[jdx]=malloc(num_members)) == NULL ) {

if( (chunk->data[jdx]=malloc(num_members*size)) == NULL ) {

Well, darn. I was really hoping I had managed to make mistakes that
were at least subtle enough so that *I* couldn't see them.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Eric Sosman]

Christopher Benson-Manica wrote On 05/09/07 10:15,:

[... simulate large allocation with multiple small allocations
and "accessor" functions ... code snipped (and examined only
briefly ...]

Were (are?) there implementations where this strategy (or something
along the same lines but undoubtedly more sophisticated) might have
been required to work around a malloc() that was too silly to work out
the details for itself?

A "buddy system" malloc (binary, Fibonacci, whatever)
will not coalesce adjacent free areas if they are not buddies.

Implementations that strive for other kinds of efficiencies
(e.g., minimal lock contention in multi-threaded environments)
might postpone coalescing adjacent free areas until the stars
are right.

Even if free areas are coalesced aggressively, there can
still be fragmentation problems. J.M. Robson showed that
fragmentation can cause allocation failure when memory is
only about two-thirds occupied, even if the allocations come
in only two sizes. (See Knuth TAOCP section 2.5 exercises
36 through 38.)

Conclusion: One need not presume a "silly" malloc to
make subdividing large allocations worth while.

This question gives rise to another point - a function that allows the
user to query the malloc() implementation and determine the maximum
number of objects with a given size that it will accept an allocation
request for would really be handy. I wouldn't think that such a
function would be difficult for the malloc() implementor to provide,
assuming that the caller accepts the obvious performance penalty.
This would allow code that needs a substantial but arbitrary amount of
space to easily ask malloc(), "How much space can I have? Ok, that's
enough, give me all of it." Was such a function considered? (I can
take this followup question to comp.std.c if need be.)

I have no idea whether such a facility was considered
in the standardization debates.

... but at a PPOE I did a fairly sizeable amount of work
on a rather more elaborate memory manager that provided a
related capability (for some of the memory pools it managed).
It answered the analogue of "How much larger can realloc()
make such-and-such an area without needing to relocate its
contents?" In the course of porting our product to its first
64-bit platform, I found that this function was expending
enormous amounts of time and started looking for ways to
speed it up.

The problem occurred when the area in question was at
the "end" of allocated memory: on a 64-bit system there was
an unthinkably large amount of unused virtual memory right
after that area, and the whole system was churning around
trying to figure out how much swap it would be able to find.
There didn't seem to be an obvious way to answer the question
with acceptable efficiency. So I turned my attention away
from the slow function and toward its callers; what use were
they making of the answer? Lo! there were only about half
a dozen callers, and they all did something like

if (fragSize(ptr) >= what_i_need)
do_this();
else
do_that();

So I wound up jettisoning the troublesome function and
replacing it with the analogue of "Would realloc() need to
relocate the area if asked to expand it to such-and-such
a size?", which was far more tractable. The callers all
became

if (canReallocInPlace(ptr,what_i_need))
do_this();
else
do_that();

.... and it was a beautiful day in the neighborhood.

The point of this long-winded anecdote is that I have
some reason to doubt the usefulness of "What's the most
space I can have?" Even if you could ask it, following
with "Give me all of it" seems a dangerous next step, one
that is likely to cause almost immediate memory exhaustion
leading to failure or bad performance (think of subsequent
malloc() calls all returning NULL, of fopen() failing or
producing only unbuffered I/O streams, and so on). It's a
question that may seem interesting at first glance, but
I'm not so sure it would turn out to be all that useful.

The related question "Can I have N bytes?" is another
matter altogether -- and the C library already provides
the means to answer it.

canReallocInPlace() is not part of the library, and
something along those lines might make a useful addition.
Might not play well with multi-threaded programs, though
(by the time you get the answer, it could be outdated).

--
Er*********@sun.com

[karl malbrain]

"Christopher Benson-Manica" <at***@faeroes.freeshell.orgwrote in message
news:f1**********@chessie.cirr.com...

Some recent posts got me thinking about how one might have dealt with
simplistic malloc() implementations which might return NULL for a 64K
request but might accept two 32K requests or four 16K requests. (I'm
assuming, perhaps incorrectly, that quality modern implementations
will coalesce free space as necessary and if possible to satisfy
requests.) I came up with the following (compilable but untested)
first cut at code to try a combination of smaller allocations:

(...)

Were (are?) there implementations where this strategy (or something
along the same lines but undoubtedly more sophisticated) might have
been required to work around a malloc() that was too silly to work out
the details for itself?

In my allocator the free status of the block with a given granularity is
kept in a separate array of bits. Free just sets the appropriate number of
bits and returns, while malloc scans through the array looking for the
required number of adjacent bits set.
Several arenas with different granularities are used so that no allocation
requires more than 32 bits. You can check out the code at my website:
www.geocities.com/malbrain.

This question gives rise to another point - a function that allows the
user to query the malloc() implementation and determine the maximum
number of objects with a given size that it will accept an allocation
request for would really be handy.

You're welcome to add an appropriate bit scanner to determine these
quantities from the arenas.

karl m

[Christopher Benson-Manica]

Eric Sosman <Er*********@sun.comwrote:

"How much larger can realloc()make such-and-such an area
without needing to relocate its contents?"

The problem occurred when the area in question was at
the "end" of allocated memory: on a 64-bit system there was
an unthinkably large amount of unused virtual memory right
after that area, and the whole system was churning around
trying to figure out how much swap it would be able to find.

Aha, yes, I can certainly see that being a problem. I guess I'm
comforted by the fact that some folks got paid to make the same naive
assumption I made for free ;-)

The point of this long-winded anecdote is that I have
some reason to doubt the usefulness of "What's the most
space I can have?" Even if you could ask it, following
with "Give me all of it" seems a dangerous next step...

Yes, your (much appreciated) anecdote definitely demonstrated that my
initial question and response were poorly conceived.

The related question "Can I have N bytes?" is another
matter altogether -- and the C library already provides
the means to answer it.

Well, yes, although I do think perhaps it might be beneficial to be
able to ask it in a slightly different way as well as the current way.
For example, code that attempted to obtain a certain amount of memory
in any combination of chunks might (if I were writing it) want to ask,
"Can I have space for M obects of size N?" and get a response "No, but
you can have space for M-1 of those, and maybe if you ask me nicely I
might give you some more space for that last object". This question
can be answered with malloc() only by calling malloc( M*N ) up to M-1
times to see whether the request will succeed or not, which isn't very
efficient.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Bart van Ingen Schenau]

Christopher Benson-Manica wrote:

Some recent posts got me thinking about how one might have dealt with
simplistic malloc() implementations which might return NULL for a 64K
request but might accept two 32K requests or four 16K requests. (I'm
assuming, perhaps incorrectly, that quality modern implementations
will coalesce free space as necessary and if possible to satisfy
requests.)

I think all implementations will coalesce free space, but only if it has
two (or more) *adjacent* free memory blocks.
The big problem is that most C implementations use raw memory addresses
for pointers, and are therefor not able to move pieces of allocated
memory around in order to create a larger block of free memory.

Therefor, a request for one large block may fail, while several requests
for smaller blocks (amounting to the same total amount of memory being
allocated) succeed.

I came up with the following (compilable but untested)
first cut at code to try a combination of smaller allocations:

#include <stdlib.h>
#define MAX_SUBCHUNKS 4

/* Functions for accessing individual chunk members omitted */

struct chunk {
void *data[MAX_SUBCHUNKS];
int num_subchunks;
/* Needed by chunk accessors to correctly calculate which subchunk a
* requested member will be in, given that the division of members
* in subchunks is done in a known way, as below */
size_t nmemb;
size_t size;
};

struct chunk *allocate_chunk( struct chunk *chunk, size_t nmemb,
size_t size ) {
size_t idx, jdx;
int succeeded;
chunk->nmemb=nmemb;
chunk->size=size;
for( idx=0; idx < MAX_SUBCHUNKS; idx++ ) {
chunk->num_subchunks=idx+1;
succeeded=1;
for( jdx=0; jdx < idx; jdx++ ) {
size_t num_members=nmemb/(idx+1)+( nmemb%(idx+1)>jdx ? 1 : 0 );
if( (chunk->data[jdx]=malloc(num_members)) == NULL ) {
succeeded=0;
break;
}
}
if( !succeeded ) { /* One of the suballocations failed - free all
existing allocated space */
for( jdx=0; jdx < idx; jdx++ ) {
if( chunk->data[jdx] != NULL ) {
free( chunk->data[jdx] );
}
else {
break;
}
}
continue; /* Try again with more subchunks */
}
return chunk;
}
return NULL; /* Couldn't allocate memory in any combination of
subchunks */
}

int main(void) {
return 0;
}

Were (are?) there implementations where this strategy (or something
along the same lines but undoubtedly more sophisticated) might have
been required to work around a malloc() that was too silly to work out
the details for itself?

This question gives rise to another point - a function that allows the
user to query the malloc() implementation and determine the maximum
number of objects with a given size that it will accept an allocation
request for would really be handy. I wouldn't think that such a
function would be difficult for the malloc() implementor to provide,
assuming that the caller accepts the obvious performance penalty.
This would allow code that needs a substantial but arbitrary amount of
space to easily ask malloc(), "How much space can I have? Ok, that's
enough, give me all of it." Was such a function considered? (I can
take this followup question to comp.std.c if need be.)

Such a function would only be useful if your program has exclusive
access to the memory and does not use <OTmultiple threads </OT>.
Otherwise, the value you got from that function could already be invalid
by the time you actually try to allocate the memory.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[Chris Dollin]

Eric Sosman wrote:

canReallocInPlace() is not part of the library, and
something along those lines might make a useful addition.
Might not play well with multi-threaded programs, though
(by the time you get the answer, it could be outdated).

Could that not be answered with a `reallocInPlace` which
reuses the space if it can and returns null if it can't?
(The malloc family would have to be robust against multi-
threading anyway.)

--
Fragmented Hedgehog
"Who do you serve, and who do you trust?" /Crusade/

[CBFalconer]

Chris Dollin wrote:

Eric Sosman wrote:

> canReallocInPlace() is not part of the library, and
something along those lines might make a useful addition.
Might not play well with multi-threaded programs, though
(by the time you get the answer, it could be outdated).

Could that not be answered with a `reallocInPlace` which
reuses the space if it can and returns null if it can't?
(The malloc family would have to be robust against multi-
threading anyway.)

That can be handled by the existing system:

if (tmp = realloc(whatever, newsize)) {
if (tmp == whatever) tmp = OK; /* realloced in place */;
else realloc = tmp;
}
else {
/* realloc failed */
}

tmp == NULL signals failure. tmp == OK signals in place (OK).
Other values signal realloc success.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

Chris Dollin wrote:

Eric Sosman wrote:

> canReallocInPlace() is not part of the library, and
something along those lines might make a useful addition.
Might not play well with multi-threaded programs, though
(by the time you get the answer, it could be outdated).

Could that not be answered with a `reallocInPlace` which
reuses the space if it can and returns null if it can't?
(The malloc family would have to be robust against multi-
threading anyway.)

That'd be one way to package it. Another might be a
realloc-like call that distinguished three outcomes: failure,
success (unmoved), and success (relocated).

Hmmm... reallocInPlace() would most likely be more usable.
The "in place" property is probably only important if you have
pointers aiming into the reallocated data (perhaps contained
within it), and if the allocation moves the data the pointers
need to be reconstituted. However, once the data moves it's
too late for `new_ptr = old_ptr - old_base + new_base'; using
the now-invalid old_ptr and old_base invokes undefined behavior.
After a reallocInPlace() failure, one could prepare a table of
offsets, then do an ordinary realloc(), and then repair the
pointers.

I'm not so sure there's a really compelling need for
the facility, though. It seems more useful than "Give me all
the memory I can get," but still may not be useful enough
to fret about.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Chris Dollin]

CBFalconer wrote:

Chris Dollin wrote:

>Eric Sosman wrote:

>> canReallocInPlace() is not part of the library, and
something along those lines might make a useful addition.
Might not play well with multi-threaded programs, though
(by the time you get the answer, it could be outdated).

Could that not be answered with a `reallocInPlace` which
reuses the space if it can and returns null if it can't?
(The malloc family would have to be robust against multi-
threading anyway.)

That can be handled by the existing system:

if (tmp = realloc(whatever, newsize)) {

That doesn't work, because if realloc needed to move it, /it has
already been moved/. The intent of the hedgehog's `reallocInPlace`
is clearly that if the existing space isn't big enough, /nothing
happens/, so you can take alternative action.

--
"Who do you serve, and who do you trust?" /Crusade/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Richard Tobin]

In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

if (tmp = realloc(whatever, newsize)) {
if (tmp == whatever) tmp = OK; /* realloced in place */;

In theory, you can't compare against whatever after calling realloc().
There was a discussion a few months ago about copying it to an array
of chars before realloc()ing (or free()ing), then using memcmp().

else realloc = tmp;

I'm pretty sure you didn't mean that.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[CBFalconer]

Richard Tobin wrote:

CBFalconer <cb********@maineline.netwrote:

> if (tmp = realloc(whatever, newsize)) {
if (tmp == whatever) tmp = OK; /* realloced in place */;

In theory, you can't compare against whatever after calling realloc().
There was a discussion a few months ago about copying it to an array
of chars before realloc()ing (or free()ing), then using memcmp().

I think you can, because you are not dereferencing it. Not sure.

> else realloc = tmp;

I'm pretty sure you didn't mean that.

True. Try "else whatever = tmp;" :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

CBFalconer wrote:

Richard Tobin wrote:

>CBFalconer <cb********@maineline.netwrote:

>> if (tmp = realloc(whatever, newsize)) {
if (tmp == whatever) tmp = OK; /* realloced in place */;

In theory, you can't compare against whatever after calling realloc().
There was a discussion a few months ago about copying it to an array
of chars before realloc()ing (or free()ing), then using memcmp().

I think you can, because you are not dereferencing it. Not sure.

Pedantically speaking (and here in c.l.c. we all speak
Pedantish like natives), Richard is right. The value of a
pointer to something that has ceased to exist is indeterminate
(6.2.4p2). An indeterminate value is either an unspecified
value or a trap representation (3.17.2). An attempt to use
a trap representation as if it were a value produces undefined
behavior (6.2.6.1p5).

... and I confess that I mis-remembered the C&V, thinking
there was a shorter trail somewhere. Perhaps someone else
will find the Northwest Passage that I missed.

--
Eric Sosman
es*****@acm-dot-org.invalid

[websnarf]

On May 10, 5:14 am, Eric Sosman <[e-mail]:

Chris Dollin wrote:

Eric Sosman wrote:

canReallocInPlace() is not part of the library, and
something along those lines might make a useful addition.
Might not play well with multi-threaded programs, though
(by the time you get the answer, it could be outdated).

Could that not be answered with a `reallocInPlace` which
reuses the space if it can and returns null if it can't?
(The malloc family would have to be robust against multi-
threading anyway.)

That'd be one way to package it. Another might be a
realloc-like call that distinguished three outcomes: failure,
success (unmoved), and success (relocated).

Hmmm... reallocInPlace() would most likely be more usable.
The "in place" property is probably only important if you have
pointers aiming into the reallocated data (perhaps contained
within it), and if the allocation moves the data the pointers
need to be reconstituted. However, once the data moves it's
too late for `new_ptr = old_ptr - old_base + new_base'; using
the now-invalid old_ptr and old_base invokes undefined behavior.
After a reallocInPlace() failure, one could prepare a table of
offsets, then do an ordinary realloc(), and then repair the
pointers.

I'm not so sure there's a really compelling need for
the facility, though. It seems more useful than "Give me all
the memory I can get," but still may not be useful enough
to fret about.

Bstrings could go faster. Meaning that any implementation that
behaves like Bstring could go faster: Suppose you have a bstring
(basically a length delimited string with malloc allocated contents)
and you grow it to some size n (imaging a large n), then truncate the
length to 3 characters (without reallocing the content pointer, which
is how Bstrlib behaves), then make space for contents that is 2*n in
length. The problem is that in the case of a moving realloc it will
try to copy n characters which are all irrelevant to the new buffer of
length 2n. So you want to realloc it, but only if its in-place,
otherwise you would rather create a new string copy over the 3
characters and deallocate the old one.

One could go further with a function like this

size_t reallocInPlace (void * ptr, size_t szmin, size_t szmax);

which returns the reallocated size if at least szmin characters can be
allocated in place and attempts to allocate as much space as possible
but not exceeding szmax characters (except by some small fixed amount
required for alignment purposes). It returns 0 if no such
reallocation can be done in place, or if szmax <= szmin.

This helps Bstrings (and again, things that are like it) even more in
that when a realloc doubling would cause a move, when actually less
space is required that happens to not move, then Bstrings can get away
with a tighter allocation strategy and be able to skip moving reallocs
in some cases where they are unnecessary.

While we are at it, a function like:

size_t getAllocationSize (void * ptr);

Which simply returned the size of an allocation would be a good idea
(that would assist Bstring a little bit as well.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[CBFalconer]

we******@gmail.com wrote:

>

.... snip ...

>
While we are at it, a function like:

size_t getAllocationSize (void * ptr);

Which simply returned the size of an allocation would be a good
idea (that would assist Bstring a little bit as well.)

Such a function could seriously complicate some allocation schemes,
and might even not be possible. What's wrong with remembering
important sizes yourself?

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

CBFalconer wrote On 05/11/07 15:36,:

we******@gmail.com wrote:

... snip ...

>>While we are at it, a function like:

size_t getAllocationSize (void * ptr);

Which simply returned the size of an allocation would be a good
idea (that would assist Bstring a little bit as well.)

Such a function could seriously complicate some allocation schemes,
and might even not be possible. What's wrong with remembering
important sizes yourself?

I think what Paul is looking for is a means of finding
out how much memory was actually provided, which could be
greater than the amount requested. Sometimes it might be
substantially greater, e.g., if block sizes are rounded up
to a power of two. (Aside: Programmers who habitually make
power-of-two request sizes, perhaps out of numerological
superstition, are at risk of particularly bad outcomes.
Imagine: You ask for a megabyte, the memory manager tacks
on a little bit more for bookkeeping, and then the total
is rounded up to two megabytes -- wasting almost half the
total space!)

Slick as it sounds, though, I'm still not convinced that
its usefulness would be widespread. If it makes a lot of
trouble for the allocator (I'm not convinced of *that*,
either) and has only marginal utility, well ...

--
Er*********@sun.com

[Richard Tobin]

In article <1178918428.772707@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:

Slick as it sounds, though, I'm still not convinced that
its usefulness would be widespread. If it makes a lot of
trouble for the allocator (I'm not convinced of *that*,
either) and has only marginal utility, well ...

If such a function were considered sufficiently useful, it could be
defined to return either the allocated size or 0 if the size is
unavailable. This would have no necessary impact on allocator
implementation, and users could take advantage of the information when
available.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[websnarf]

On May 11, 12:36 pm, CBFalconer <[e-mail]:

[e-mail] wrote:

... snip ...

While we are at it, a function like:

size_t getAllocationSize (void * ptr);

Which simply returned the size of an allocation would be a good
idea (that would assist Bstring a little bit as well.)

Such a function could seriously complicate some allocation schemes,
and might even not be possible. What's wrong with remembering
important sizes yourself?

Because you have to store them somewhere? Which, besides being a
little wasteful, is a synchronization problem. I know there is
absolutely no audience for this line of reasoning in this newsgroup or
on the C standards committee, but that doesn't mean I am going to shut
up about it. Also, even if you are able to successfully track the
allocations sizes you requested, you are unaware of the extra space
you have been given due to alignment limitations. I have looked at
various heap implementations, and there is no relevance in the ones
that don't have this data sitting around somewhere anyways.

These are just the two most obvious of several functions that should
be added to the std library for memory allocation management. You
know, garbage collected language people continue to laugh at explicit
allocation languages because they have so much less work to do and its
safer. Now the explicit allocation people can always retort that
realtimeness can be supported, but cannot argue that its faster or
that there is any more control over it, except for realloc() support.

In the case of C, I find the memory manager to be a lot more opaque
than it needs to be which leads it to be a very serious impediment to
debugging. I have also determined that for any sophisticated data
types, I can implement really tight implementations, but just get
burned if they are made up of too many allocations, because malloc is
just way too slow. There are very fast heap implementations that can
be made under certain assumptions (separate heaps with a freeall()
function). Also, any kind of accounting of memory allocated or number
of allocations is generally enough information for anyone to determine
whether or not your program has a memory leak in it.

These things are all *possible*, in the C language and would give it
more capabilities and performance advantages over other languages that
rely on GC. But so long as nobody cares or notices, these things will
just remain in private implementations being rewritten over and and
the GC people will go unanswered when they refer to C as just another
COBOL.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/