The Shrine

If asked a few years ago, I would have thought the chances of having to write this line of code would be slim:

Hilarious!

I'm curious enough to ask. How did you get into a member function if the this pointer is NULL?

Unless it's static, but you still need to make sure that the function was called from an object and not using the :: operator...

The <tt>this</tt> pointer does not exist in static member functions; by definition, a static member function is not associated with a particular object.

But to answer your question, I'm debugging a multithreaded allocator. (Although this could happen even in single threaded code; there's nothing to prevent you from corrupting the stack, which is what it appears the allocator is doing.)

What does the "assert()" function do?

It's an old C library function. If the predicate passed to it evaluates to false, then it prints to standard error that the predicate failed and exits the program. It's an assertion that the predicate had better be true, and if it's not, bail out now and give some useful debugging info.

Makes sense from a security POV. I imagine there would be a lot of these at certain places in sensitive code to ensure that the pointer or other variables aren't corrupted.

Not so much...though Kup can correct me on this as usual.

assert() is really old, and I would imagine anyone using C++ or another more modern language would be using exceptions instead. assert() will exit your program completely if it fails, so it's not a great choice for anything that has to keep working even if memory/other stuff gets corrupted. Exception handling provides a mechanism whereby a program checks conditions, similar to an assertion, but can pass off execution to another part of the program if the "assertion" (called a try block) fails.

It's a little complicated though in the specifics, and I'm sure Kup could explain better than I.

The uses of <tt>assert()</tt> are much more narrow than exceptions. An exception is saying basically "Something really bad happened and I have no idea how to handle it. <i>You</i> figure it out" where <i>You</i> is someone up the call stack. So throwing an exception does not necessarily mean the program is over and done, the program might be able to recover and continue execution. Uncaught exceptions will cause a runtime error and generally say something on standard error. So exceptions can be used for error recovery (when they're caught) or debugging info (when they're not caught).

An assertion, however, is not as flexible. If the assertion fails, the program exits. Unlike exceptions, assertions are not useful for error recovery, only debugging. They're extremely useful for debugging, through, because you can throw assertions in code at various places to test your assumptions. Assertions also generally tell you which file and the line of code that failed. You can get the same effect with exceptions, but it's generally easier to write <tt>assert(<i>something that needs to be true</i>)</tt> than it is to come up with a meaningful exception class.

Akin to die() in Perl. Also, there might be points were you want assert in real code, like say, something vastly unusual has gone awry in the code, and you don't even want to risk jumping to a error handler at this point. Sort of like a kernel panic.