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.
Well, the statement is more in reply to the claim that aborting is generally the least bad option than the latter part of that quote. I don't think we ever want memory corruption, no, but I also don't think those three options are the only three we have.
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.
If you're arguing that not every library is particularly good at handling error conditions, sure, no argument from me. I'd still argue that you want abort() rather than assert() in those cases, and that it should be more of a last resort than the first thing to reach for.
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.
Do you have some specific cases in mind?
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.
Yeah, they should.
To give an example, spirv_compiler_find_resource() has an "assert(entry);", that essentially asserts that resources referenced by instructions have been previously declared. That's not an unreasonable thing to require, but it's not something guaranteed by either the TPF or d3dbc parsers.
In the HLSL compiler, sm4_base_type() for example calls vkd3d_unreachable() for unexpected/unhandled types, and HLSL_SAMPLER_DIM_BUFFER/D3D_SVT_RWBUFFER is one of those.