Incidentally, still not a fan of assert() in library code.
And I still don't understand why: they are very useful comments, they catch errors and if somebody does not like them it's easy to turn them off with `NDEBUG`, so the user ultimately has the choice to compromise between detecting problems early and keep going and hoping everything's fine. Removing assertions takes away advantages without giving any advantage that can't be easily obtained already with `NDEBUG`.
Fundamentally, because I don't think libraries should call abort(). Libraries only rarely know the full context they're running in; aborting other people's code is at best rude, and could e.g. have security implications or cause data loss in less benign cases. 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. - NDEBUG isn't quite as easy when you're using distribution packages. And if the issue we're detecting is indeed bad enough to justify aborting the application, NDEBUG doesn't make it better, it just hides the issue a little longer. - assert() isn't an error handling/reporting mechanism. vkd3d-shader should generally use vkd3d_shader_verror() for that. If we want vkd3d_shader_verror() to abort() for easier debugging, fine; add a local patch that does that, or introduce a VKD3D_SHADER_CONFIG flag. I don't think it should be the default behaviour.