Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why does C not have a heap checking function?

jandrese (485) writes | more than 7 years ago

Programming 4

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 byOne 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?

Sorry! There are no comments related to the filter you selected.

Your teacher is right (0)

Anonymous Coward | more than 7 years ago | (#20590113)

Your program should be able to keep track of the size. Poor design is no excuse. If you have team problems and too many lazy libraries, then you could make a allocation type which has the size and allocation. Malloc does not track the size you requested to be allocated, but only tracks the size of the space used by the allocation which is usually larger. I'm not talking about headers, which are very minimal. Allocation requests are rounded up to the next normal size, which is different depending on implementation.

Re:Your teacher is right (1)

jandrese (485) | more than 7 years ago | (#20756307)

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 (1)

Chacham (981) | more than 7 years ago | (#20626589)

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 easy way out, and do the opposite of what i just said. But then either don't complain when a lazy function isn't added, or just add it yourself. The source is out there.

And now, disregard everything i just said. I have hardly done any C outside of a text book.

Re:Moo (1)

jandrese (485) | more than 7 years ago | (#20756265)

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 going into it without sending some sort of metadata along side it (see fgets vs. gets for an example everybody knows about), and even then you have to trust the metadata the programmer sent (no non-trivial program is ever completely error free) instead of just asking the system directly.

The answer of "well, you need to code more carefully" is not a good one to me since even when you are careful it's extremely difficult to foresee all possible failure modes and impossible to sanity check. All I'm asking for is a mechanism by which I can sanity check my buffers before I use them.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?