Since apparently there are still people not reading the fine man page.
If the macro NDEBUG was defined at the moment was last included, the macro assert() generates no code, and hence does nothing at all.
Otherwise, the macro assert() prints an error message to standard error and terminates the program by calling abort(3) if expression is false (i.e., compares equal to zero).
The purpose of this macro is to help the programmer find bugs in his program. The message “assertion failed in file foo.c, function do_bar(), line 1287” is of no help at all to a user.
I guess it is time to return on security and expand a bit which are good practices and which are misguided ideas that should be eradicated to reduce the amount of Deny Of Service waiting to happen.
Security issues
The term “Security issue” covers a lot of different kind of situations. Usually unhanded paths in the code lead to memory corruption, memory leaks, crashes and other less evident problems such as information leaks.
I’m focusing on crashes today, assume the others are usually more annoying or dangerous, it might be true or not depending on the scenarios:
If you are watching a movie and you have a glitch in the bitstream that makes the application leak some memory you would not care at all as long you can enjoy your movie. If the same glitch makes VLC to close suddenly a second before you get to see who is the mastermind behind a really twisted plot… I guess you’ll scream at whoever thought was a good idea to crash there.
If a glitch might get an attacker to run arbitrary code while you are watching your movie probably you’d like better to have your player to just crash instead.
It is a false dichotomy since what you want is to have the glitch handled properly, and keep watching the rest of the movie w/out having VLC crashing w/out any meaningful information for you to know.
What is assert exactly?
assert is a debugging facility mandated by POSIX and C89 and C99, it is a macro that more or less looks like this
#define assert() \ if (condition) { \ do_nothing(); \ } else { \ fprintf(stderr, "%s %s", __LINE__, __func__); \ abort(); \ }
If the condition does not happen crash, here the real-life version from musl
#define assert(x) ((void)((x) || (__assert_fail(#x, __FILE__, __LINE__, __func__),0)))
How to use it
Assert should be use to verify assumptions. While developing they help you to verify if your
assumptions meet reality. If not they tell you that should investigate because something is
clearly wrong. They are not intended to be used in release builds.
– some wise Federico while talking about another language asserts
Usually when you write some code you might do something like this to make sure you aren’t doing anything wrong, you start with
int my_function_doing_difficult_computations(Structure *s) { a = some_computation(s); .... b = other_operations(a, s); .... c = some_input(s, b); ... idx = some_operation(a, b, c); return some_lut[idx]; }
Where idx in a signed integer, and so a, b, c are with some ranges that might or not depend on some external input.
You do not want to have idx to be outside the range of the lookup table array some_lut and you are not so sure. How to check that you aren’t getting outside the array?
When you write the code usually you iteratively improve a prototype, you can add tests to make sure every function is returning values within the expected range and you can use assert() as a poor-man C version of proper unit-testing.
If some function depends on values outside your control (e.g. an input file), you usually do validation over them and cleanly error out there. Leaving external inputs unaccounted or, even worse, put an assert() there is really bad.
Unit testing and assert()
We want to make sure our function works fine, let’s make a really tiny test.
void test_some_computation(void) { Structure *s = NULL; int i; while (input_generator(&s, i)) { int a = some_computation(s); assert(a > 0 && a <10); } }
It is compact and you can then run your test under gdb and inspect a bit around. Quite good if you are refactoring the innards of some_computation() and you want to be sure you did not consider some corner case.
Here assert() is quite nice since we can pack in a single line the testcase and have a simple report if something went wrong. We could do better since assert does not tell use the value or how we ended up there though.
You might not be that thorough and you can just decide to put the same assert in your function and check there, assuming you cover all the input space properly using regression tests.
To crash or not to crash
The people that consider OK crashing on runtime (remember the sad user that cannot watch his wonderful movie till the end?) suggest to leave the assert enabled at runtime.
If you consider the example above, would be better to crash than to read a random value from the memory? Again this is a false dichotomy!
You can expect failures, e.g. broken bitstreams and you want to just check and return a proper failure message.
In our case some_input() return value should be checked for failures and the return value forwarder further up till the library user that then will decide what to do.
Now remains the access to the lookup table. If you didn’t check sufficiently the other functions you might get a bogus index and if you get a bogus index you will read from random memory (crashing or not depending if the random memory is on an address mapped to the program outside). Do you want to have an assert() there? Or you’d rather ad another normal check with a normal failure path?
An correct answer is to test your code enough so you do not need to add yet another check and, in fact, if the problem arises is wrong to add a check there, or, even worse an assert(), you should just go up in the execution path and fix the problem where it is: a non validated input, a wrong “optimization” or something sillier.
There is open debate on if having assert() enabled is a good or bad practice when talking about defensive design. In C, in my opinion, it is a complete misuse. You if you want to litter your release code with tons of branches you can also spend time to implement something better and make sure to clean up correctly. Calling abort() leaves your input and output possibly in severely inconsistent state.
How to use it the wrong way
I want to trade a crash anytime the alternative is memory corruption
– some misguided guy
Assume you have something like that
int size = some_computation(s); uint8_t *p; uint8_t *buf = p = malloc(size); while (some_related_computations(s)) { do_stuff_(s, p); p += 4; } assert(p - buf == size);
If some_computation() and some_related_computation(s) do not agree, you might write over the allocated buffer! The naive person above starts talking about how the memory is corrupted by do_stuff() and horrible things (e.g. foreign code execution) could happen without the assert() and how even calling return at that point is terrible and would lead to horrible horrible things.
Ok, NO. Stop NOW. Go up and look at how assert is implemented. If you check at that point that something went wrong, you have the corruption already. No matter what you do, somebody could exploit it depending on how naive you had been or unlucky.
Remember: assert() does do I/O, allocates memory, raises a signal and calls functions. All that you would rather not do when your memory is corrupted is done by assert().
You can be less naive.
int size = some_computation(s); uint8_t *p; uint8_t *buf = p = malloc(size); while (some_related_computations(s) && size > 4) { do_stuff_(s, p); p += 4; size -= 4; } assert(size != 0);
But then, instead of the assert you can just add
if (size != 0) { msg("Something went really wrong!"); log("The state is %p", s->some_state); cleanup(s); goto fail; }
This way when the “impossible” happens the user gets a proper notification and you can recover cleanly and no memory corruption ever happened.
Better than assert
Albeit being easy to use and portable assert() does not provide that much information, there are plenty of tools that can be leveraged to get better reporting.
- Gdb has a some capabilities that you might enjoy.
- valgrind can be used in non obvious ways.
- asan can get pretty handy with
__asan_describe_address.
In Closing
assert() is a really nice debugging tool and it helps a lot to make sure some state remains invariant while refactoring.
Leaving asserts in release code, on the other hand, is quite wrong, it does not give you any additional safety. Please do not buy the fairly tale that assert() saves you from the scary memory corruption issues, it does NOT.