The whole point of abort() is that, rude as it is, it's generally the least rude option. It's far safer and more polite than things like (a) pretending to succeed but giving incorrect output; (b) crashing a greater distance away from the root cause, e.g. inside the library user's code.
I don't think that's a decision a library can reliably make.
I find this statement bizarre. I cannot think of an instance where I would ever want a library to yield incorrect results or corrupt memory instead of crashing.
Moreover:
- Aborting the application may be appropriate in some cases. If the reason the assert gets triggered is e.g. memory corruption, perhaps it makes sense to abort the application. Unfortunately we don't know that in advance; for something like e.g. https://bugs.winehq.org/show_bug.cgi?id=55190, I think aborting is worse that the issue being detected.
The tests don't make it clear, but if we just removed that assertion, we'd be outputting incorrect code. How is that better than aborting?
It mostly depends on the context we're running in. If we're being fed malicious input, returning incorrect output may very well be the better option. But those aren't the only two options we have, of course. For the cases where incorrect output would be the worst that could happen, I think the right answer is pretty much vkd3d_shader_error().
To be clear, as far as vkd3d-shader is concerned, sure, we can use vkd3d_shader_error() and that's generally at least as pleasant as assert(), i.e. it allows the program to avoid aborting in some cases while still providing exactly as much information to a developer.
But I want to press this issue regardless, because vkd3d-shader is a bit special in that its architecture is friendly to reporting errors at an arbitrary point. You can't ICE from any given library, at least not without introducing an inordinate amount of API structure for it.
I also want to press this issue because if the point is that the library should never do anything that *might* crash—if all of our assertions should be replaced with graceful handling—I cannot see that as even close to feasible.
Even if that example ended up being fine in practice, well, we wouldn't have known it in advance. assert() catches invariants that could result in *anything* if violated.
In theory, sure. In practice, I think we have a number of cases where assert() is essentially used as a substitute for input validation. It also tends to make review a bit harder; instead of verifying the condition is handled appropriately, the reviewer needs to verify it can never happen.
Huh? We do? I've been specifically trying to avoid ever using assert() for user input, because that's certainly not appropriate. If we have any such cases they should be fixed.