3 ms·
That's a very normal use if asserts - no point in a running but broken program if important programmer assumptions failed, and a coredump is more useful for deb
by arghwhat 3y ago
That's a very normal use if asserts - no point in a running but broken program if important programmer assumptions failed, and a coredump is more useful for debugging than an error message.
- ahoka 3y agoBut C assert.h checks can be disabled by setting NDEBUG and sometimes are for production builds. It’s not meant for bounds checking or anything that required for correctness, but for asserting invariants, hence the name.
- sph 3y agoIt's a blog post to teach about Wayland, not a production app. If one creates an app by copy-pasting this code, blame them, not the author.
- arghwhat 3y agoYes you can actively disable it. You can also pass "-gcflags=-B" to Go to disable bounds checking, and Rust disables runtime overflow checks in release mode by default. Doesn't make the use any less valid.
- LoganDark 3y agoIn-bounds accesses should be an invariant. A program that is capable of even attempting an out-of-bounds access is probably incorrect. With that said, I would not be confident enough to allow bounds checks to be disabled. (Rust is my favorite.)
- diath 3y agoConsider this - you may not be able to hit your assumption with all possible inputs in debug/during development, or your function may accept user-provided input, you then release your software, and then somebody gets your code executed with a set of inputs that don't pass the assumption, now since it's an assert that's been effectively turned into a no-op in release, you're reading past the end of the buffer.
- arghwhat 3y agoasserts are not disabled in release builds unless you explicitly go out of your way to do so.
- josefx 3y agoVarious build tool chains disable them implicitly for release builds. You should probably assert #ifdef NDEBUG #error #endif In your source code if your code assumes that assertions will never be disabled.