Is ASSERT redundant?

Question

ASSERT(pointer);
pointer->x;

In this code, the ASSERT seems to be redundant. If the pointer is NULL, pointer->x will fail anyway. Is my argument correct?

Answer 1

Yes, but pointer->x will (I presume) fail in an uncontrolled way, whereas the assert will fail and tell you exactly where.

In some sense, assert is always redundant, of course.

Answer 2

No, it's not redundant. The assertion will stop execution before anything bad happens. On the other hand, if you dereference an invalid pointer you might cause real corruption, or at the very least an uncontrolled segfault rather than a controlled abortion.

Answer 3

On some cases assert can be used for debugging http://simonwillison.net/2008/May/22/debugging/

Answer 4

The ASSERT is not to fail. It is here to stop a debugger on a breakpoint. This will not affect a release build.

Answer 5

The important (if not main) purpose of assertions is to document the invariants that are supposed to hold at certain point in the code. The fact that assert can also abort the program if the invariant is broken is just icing on the cake, albeit a very useful one. I'd say that in a typical program 90% of assertions are assertions that rather obviously can't fail and never will fail. In other words, assert is to a large degree a kind of formalized comment language. Formalized in a sense that these "comments" are written in the same language the rest of the code is written in (C/C++), as opposed to plain English.

In your code sample the assertion is there to tell you that the pointer is not supposed to be null here. That's why it is there. In that sense this assert is not redundant.

As far as the execution flow is concerned, assert is always redundant, which is why assertions are typically not compiled in the release version of the code. There's nothing to prevent you from keeping the assertions in release code as well, but normally it is done by introducing a special kind of "release assertion". In any case, making the main functionality of the code depend in the actions taken by an assertion is not a good programming practice. Assertions are supposed to be redundant, as far as the main functionality of the code is concerned.

Answer 6

ASSERT is not part of the C standard, so could be anything

 #define ASSERT(x) do { \
     x = malloc ( sizeof *x ); \
     memset ( x, 0, sizeof *x );\
     } while ( 0 )

assert is a different matter.

Some people have an ASSERT macro which calls the debugger, some have one which does other debugging or logging, and use the stringification feature of the pre-processor.

You really have to say what the macro does for anyone to know whether it is important.

Answer 7

ASSERT can also be used to check for invalid or illogical conditions that may not cause a crash. Here's a horribly contrived example:

void cpu_hog(int duration)
{
    int start_time = (int) time(NULL);
    int end_time   = start_time + duration;

    ASSERT(end_time > start_time);  /* If this fails, "int" is too small. */

    while ((int) time(NULL) < end_time)
        ;
}

One small note: most proponents of ASSERT recommend you use it only to validate the assumptions you make as you write the code (for example, a pointer is non-NULL, or a condition cannot occur). It's generally considered a bad idea to use ASSERT to trap user-related errors or exceptions that are expected to occur (for example, disk full) because (1) ASSERT exists only in a debug build, and (2) even if you promote your debug code to production, it will crash instead of handling the condition gracefully.