Hacker News Reader

Comment by jdmt | Hacker News Reader

Why do you do things like:

  assert(doSomethingThatChangesState() == 0);

throughout your code? I thought the point of assert was for debugging purposes and you should never change program state inside the assertion.

View on HN

I prefer to fail as soon as possible. I use asserts in places where there is no good way to recover from a failed invariant.

Failing immediately is certainly an easy way to handle unrecoverable errors. However, it seems as though your library assumes NDEBUG is never defined. Maybe you should make your own function rather than using assert()?

The asserts are in the .c files. Defining NDEBUG in your program won't change anything in lthread because the library was compiled without NDEBUG defined.

If you want to define NDEBUG when compiling lthread, that's up to you.

If you compile

assert(foo(bar) == 0);

with NDEBUG, foo will never even be called. I've seen some funky bugs from this in the past, like people calling malloc inside an assertion... Works great during dev, release build has NDEBUG defined, no test coverage... You get the picture.

A better idea would be to capture the return value in a var and do the assert on the var.

Yes I understand that foo() won't be called if you defined NDEBUG. But when compiling lthread, NDEBUG is not defined anywhere in the code / makefiles so it's guaranteed to be called and I want to assert the returned value.

Reply on news.ycombinator.com