jandrese's Journal: Why does C not have a heap checking function?

One of the things that has bothered me from the first day I learned about the Memory Management in C over a decade ago is how there is no apparently method in C for knowing how much memory is allocated behind a pointer that you are passed. I asked my teacher back in the day how we would prevent stuff from running off of the end of a buffer if we can't find out how big a buffer is and he just shrugged his shoulders and said "very carefully". It is no surprise to me that buffer overflows are by far the most common form of exploit on C based languages. The worst part is that a lot of that could be avoided with one simple function:

int heapsize(void* buffer, void** start);

Passed in your target pointer it would set the start pointer to the start of the buffer and return the length of the buffer in bytes. Now you would know exactly where your pointer is and how many bytes are left. Bounds checking suddenly gets really simple and buffer overflows, while not completely a thing of the past (lazy programmers would never check), appear far less often.

The normal argument against this function is "it's your program, you should know how big the buffers are", but frankly in an age of libraries and team coding this is just not true.

The worst part is that C already knows this stuff. It has to or the "free" command would not work. It is just hidden away and impossible to get at for some reason. Even with the many revisions of C over the years, it seems like this is one feature we're never going to get. I wonder why?

Re:

[jandrese]

So why not stick the actual requested size in the header? I know it's overhead and C compiler writers hate overhead, but the other option of virtually every major program in the world being rife with buffer overflow exploits seems like a bad one. If you don't think your major C program has a buffer exploit somewhere, then you're deluding yourself. The reason is that it is impossible to sanity check buffers before you use them in C, and thus such exploits are almost inevitable.

Moo

[Chacham]

The normal argument against this function is "it's your program, you should know how big the buffers are", but frankly in an age of libraries and team coding this is just not true.

Remind me never to hire you. :)

It *is* your code, and you *should* know what you are doing with it. Don't rely on functions, or hints, or anything. Don't name variables with the type in front, that's just wrong [slashdot.org].

The way to work is to design it well, and code away. Any questions? Go back to the design.

Of course, you could take the e

Re:

[jandrese]

Empirical evidence suggests that in the real world this is a big problem though. On small projects where all of the interactions are well known by every programmer it's not too bad to keep close tabs on what every part is doing, but as the project gets bigger the number of interactions you need to keep track of grows exponentially.

The real complaint I have is when I'm doing error checking. In C it's simply not possible to check and see if the buffer passed into your function is large enough for the data