Results 1 to 9 of 9

Thread: c language malloc() and c++ new quirk....

  1. #1
    Silent Key Member 5-25-2015 W1GUH's Avatar
    Join Date
    Aug 2008
    Location
    NYC
    Posts
    10,471

    c language malloc() and c++ new quirk....

    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!
    If it's a war on drugs, then free the POW's.

  2. #2
    Volcano Tamer
    Join Date
    Oct 2009
    Location
    Buffalo, NY
    Posts
    22,581
    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.
    Big Giant Meteor 2020 - We need to make Earth Great Again

    http://www.coreyreichle.com

  3. #3
    Silent Key Member 5-25-2015 W1GUH's Avatar
    Join Date
    Aug 2008
    Location
    NYC
    Posts
    10,471
    Aw, without malloc() we'd never have the fun of creating memory leaks!
    If it's a war on drugs, then free the POW's.

  4. #4
    Volcano Tamer n2ize's Avatar
    Join Date
    Dec 2007
    Location
    Crestwood, New York
    Posts
    33,863
    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.
    I keep my 2 feet on the ground, and my head in the twilight zone.

  5. #5
    Volcano Tamer kf0rt's Avatar
    Join Date
    Jan 2007
    Location
    Denver 'burbs
    Posts
    11,068
    Quote Originally Posted by n2ize View Post
    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.

    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:

  6. #6
    Volcano Tamer n2ize's Avatar
    Join Date
    Dec 2007
    Location
    Crestwood, New York
    Posts
    33,863
    Quote Originally Posted by kf0rt View Post
    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.

    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:
    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.

    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.
    Last edited by n2ize; 08-01-2010 at 01:52 PM.
    I keep my 2 feet on the ground, and my head in the twilight zone.

  7. #7
    Volcano Tamer kf0rt's Avatar
    Join Date
    Jan 2007
    Location
    Denver 'burbs
    Posts
    11,068
    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.

  8. #8
    Silent Key Member 5-25-2015 W1GUH's Avatar
    Join Date
    Aug 2008
    Location
    NYC
    Posts
    10,471
    Quote Originally Posted by kf0rt View Post
    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."
    If it's a war on drugs, then free the POW's.

  9. #9
    Snarky Dick ka8ncr's Avatar
    Join Date
    May 2008
    Posts
    2,475
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •