[NSWI004] Why are assertions ignored in test mode.

[Vojtech Horky]

Hello.

Dne 12. 11. 20 v 19:47 Jan Kytka napsal(a):
> Is there a good reason, why are regular assertions ignored when the 
> kernel is built for testing?
> 
> i.e shouldn't the lines 28,29 in include/debug.h:
> 28    #ifdef KERNEL_DEBUG
> 29    #define assert(expr) \
> 
> be more like this?
> 28    #if defined(KERNEL_DEBUG) || defined(KERNEL_TEST)
> 29    #define assert(expr) \
> 
> My point is: if my code has a bug in it, I shouldn't allow the tests to 
> let it pass.

Well, your kernel is never built differently than for testing :-).

But seriously: imagine the following function:

bool heap_is_okay() {
     foreach (used_blocks, block) {
         if (block->magic != magic) {
             return false;
         }
     }
     foreach (free_blocks, block) {
         if (block->magic != magic) {
             return false;
         }
     }
     return true;
}

With this function, it makes a very good sense to have

void *kmalloc(size_t size) {
     assert(heap_is_okay());
     ...
}

However, this is extremely slow. And once you have debugged your heap 
code, it is something that will never evaluate to false. But you do not 
want to remove it completely as it can be used in the future. I believe 
that here assert is the right choice.


Furthermore, assert it not the only construct available - there are 
other beasts with similar purpose and you can choose the one you like 
the most for a given situation.

Standard asserts that mostly document the preconditions and are supposed 
to catch developers' errors.

Tests use a different assert that is always compiled and allows to 
specify a custom, formatted message.

panic_if() function that checks conditions that can occur (such as not 
enough memory) but kernel cannot continue past them.


On a related note: we added a --configure-arg option to tester.py that 
allows you to pass extra arguments to configure.py, such as --debug.

Hope this helps,
- VH