News for hackers. Stuff that matters.
Re:The Use of assert() in SQLite by hermitdev on Friday April 26, 2019 @10:38PM (#19763423)
I'm not sure I agree. There's a very, very small limited set of conditions that a client can recover from a condition that would trigger an assertion failure. Dont want an abort? Then use the release libs where those have been preprocesed out.

Conversely, at a former employer we used a set of 3rd party database libs for ODBC on Linux that for the smallest config error would emit nothing to stderr and call exit(1) from a shared lib. that was beyond annoying

Re:The Use of assert() in SQLite by catlifeonmars on Friday April 26, 2019 @10:50PM (#19763452)
I was afraid someone would mention preprocessing out the asserts :)

That also has its advantages, but would argue that it is impossible to selectively opt in or out.

Honestly, for a well tested piece of code, the point is moot, since the assert(s) will never evaluate false anyway.

Re:The Use of assert() in SQLite by hermitdev on Saturday April 27, 2019 @10:12PM (#19768863)
> I was afraid someone would mention preprocessing out the asserts :)

Problem is, you need to understand what you're using, and like it or not, assert is defined as a macro by the C standard. And, assert is conditionally defined (and it's not the only conditionally defined macro).

I know its long, verbose, and dry; but if you want to understand C (or C++ for that matter), you really need to read the ISO standards that correspond to the implantation.

Re:The Use of assert() in SQLite by drb91 on Sunday April 28, 2019 @01:33AM (#19769533)
You can also easily enable runtime failures so the point is indeed moot.