Yep
roger that
Is null valid to pass in?
I just assert not null
It does work in "release" build?
It's not the same, yeah
I wouldn't
Just check for NULL at all callsites instead: assert(stack); push(stack, 42); and then step 2: remove the asserts at all callsites where it's obvious it's not NULL, like: stack_t stack = ...; push(&stack, 42); // no assert needed ofc
The theory is that step 2 will remove most or all assertions
You mean, just transfer responsibility for error/null checking to user?
No, he means don't check it at times when it is obviously not needed
Some functions take pointers that can be NULL, most don't, ones that don't shouldn't check, they should just segfault
Then, how do I unit test them if the app just segfaults? Or should I check only how it behaves given valid data? I'm just switching from C# to C and it highly contradicts how I used to work and deal with such situations since I treat pointers much like reference types in C# (it quite a bit helped me to get how they work) with addition that I should manually free the memory.
1. a segfault is a valid test suite failure, just not a very descriptive one 2. Yes, only test for valid data ofc, garbage in -> garbage out Imagine the scenario
I will try that approach. Writing code expecting you will get in your functions what you want is new to me. Usually my code starts from a couple of if statements validating an input data.
In this case validation is not free, and you usually control all the callsites too
Обсуждают сегодня