Printable View
Just learned this last week. The c language malloc() function stores its internal data adjacent to the memory it allocates for the user. So what happens when you write more data into the allocated memory than it can hold it'll blast malloc's internal data. From that point on malloc() will cause a segmentation fault. That bug drove me nuts til I learned that.
Same thing happens with a c++ new operator. It probably calls malloc().
Heads up!
malloc is a bane to every programmer.
Want to know what else happens if you overfill the allocation? Let's say with op code?
Another reason to avoid malloc like the plague.
Aw, without malloc() we'd never have the fun of creating memory leaks!
I haven't programmed in a while, let alone program in C or C++ so I am kind of rusty but I remeber malloc() was quite dangerous, you had to be very careful to avoid buffer overruns, etc. I actually used to know this stuff pretty well as I understood what was going on under the hood (in assembly) and why certain C functions were more finicky that others. I really need to brush up on this stuff, I have a pretty good set of notes on all this.
If your background is in assembly, you shouldn't have any problems with malloc() or it's cousins. It's usually just the folks who don't really understand memory that get into trouble with it. People with good background in assembly almost never have this problem.Quote:
Originally Posted by n2ize
Keep in mind that high-level languages are just a way to allow any moron to program faster. Under the covers, it's still running instructions. :rofl: :neener:
I found that I really didn't truly understand C or C++ until I started learning assembly. Then it all kicked in. Learning assembly also helped me to be able to debug as well. I remember once having a problem with floating point numbers. I kept getting some erroneous result and I couldn't figure out what was going on. Finally I took a look at the assembly code that the compiler was generating and it then became obvious as to what exactly was happening. I even managed to start to understand how the assembly is translated into machine instructions and, one day found myself able to change the behavior of a program to make it a bit more desirable by hand editing the binary executable file in a hex editor.Quote:
Originally Posted by kf0rt
The problem is that I quickly get rusty when I don;t use this stuff often enough. I mostly work with algorithms, trying to make them more efficient and leve the programming to someone else. Luckily I have some strong and well documented notes on assembly so, it shouldn't take me long to get myself back up to speed. True the higher level languages make things easier but, even a rudimentary understanding of assembly can help in improving the understanding of how the higher level languages work, how to debug them, how to use them with greater efficiency, make more efficient use of the registers, the stack, etc.
I really shouldn't slam C -- it's a godsend for getting things done faster, and the objectivity of C++ allows a lot of stuff that would be incredibly difficult in assembly.
But you're 100% correct that the more you understand "close to the iron" the better it all gets.
Could be why it became the standard a few years back. Having come up through the machine language/ assembly code route, c (lower case) is kind of "assembly code with high-level language constructs."Quote:
Originally Posted by kf0rt
Is an under or overwrite on heap space more dangerous than doing it on statically defined space, say char[nnnn]?
At least in the OP example, the heap is corrupted and it coredumps or gets a protected memory access violation. Zipping off the end of char[nnnn] gets you a tour somewhere north of the function's activation record. I think that is on the program stack.