Teaching old assert() new Tricks

One thing that severely hinders assertion strings is that people can't seem to decide whether the string should state the intended case or the failure case.

By contrast, being able to dump out the inputs to the failing expression is always useful. This is mostly discussed in the context of test-suite asserts, but should probably be generalized.

> and so the very first thing that will happen in the investigation will be looking at the code with the assert

And the very next thing that will happen is me swearing up and down that I wished I captured more context at the point of error so I could understand the corner case much more easily.

assert, on failure, should dump as much function and stack context as it possibly can generate; and possibly, a string tag for _user_ convenience in reporting on and differentiating for themselves the specific error condition.

mainframes are great for this. You get a custom tagged error message that conveys the subsystem, error level, and error number along with a text error string. This makes cataloging and classifying errors automatic for everyone who sees and conveys them. Then you can use the system record store to go get the context information generated at the site of the error itself and build a much clearer idea of why the particular operation failed.

One reason I like assert strings is that they can assist bug triage in a large organization, assuming that (as in my environment) the string is available outside of the core/kernel dump, probably in the kernel ring buffer/logs. Often, keying off of line number won't work across different branches, maintenance releases, patches and the like, so having a unique-ish string to search known issues/chat history/etc with is valuable. Sure, you can check out the code corresponding to the build that produced the core and find the code context from there, but that's another step that takes time, especially if you have to traverse a bunch of mappings like "oh, the core's from a machine on B_FOO_1337, which according to this one service corresponds to commit abcdef123, which is in repo baz, which I don't actually have checked out and/or fetched recently, oops." In an environment of this sort, it's also frequently not super quick or straightforward to get a debugger set up with the appropriate symbols to open the core and see the context - if a person running through a big list of defects can simply plug the string into a search and go oh, yup, it's known issue #12345 vs. having to hunt for the correct symbols, copy the (potentially several gb!) core around, get gdb to happily open it, etc, that eventually adds up to big time savings. Finally, compiler optimizations can make it so that, while a value is present in the core, the debugger can't automatically find it and gives you that <value optimized out> thing. While you usually can go digging around in the registers to extract it, that's a pain and yet more time. If you put the value(s) of the failed assertion in the string, that's one less spot for someone doing triage to get hung up on when trying to tell whether an issue is something new or just frequency of a known issue.

For stuff I'm just writing by and for myself, yeah, I take your approach. For software that will generate failures I may not be the first person in an organization to have to look at, I add friendly strings.

Even if it did, DoS is still a valid security issue that can be exploited.

> I asked if the compiler preserved the asserts when not compiling in debug mode.

What was the answer?

I spent a few hours debugging once because my code was built without asserts and I asserted that a function call in C returned true.

So this is something that one needs to be careful about and perhaps run integration/system tests with release builds.