On 23/03/15 15:01, Nicolas George wrote:
You want to crash when the impossible happens, because otherwise you are
likely corrupting the users' data or opening a security breach.
Only if you are not managing the failure properly.
The "impossible" is pretty much possible if you have an assert that
might or might not trigger.
You put asserts to have an easy debug while you develop code, leaving
them is quite wrong, doesn't matter how you justify it.
Keep in mind that asserts do get compiled out. And avassert{something}
is just addings abort() in your library code.
It is better for the users to read "assert failure" right now than "you have
been pwned" months later.
No it is better to have your user get a message "bug catched" and have
the server or client working just fine beside not having that audio stream.
Of course, an assert that is known to be triggerable must be fixed. But
asserts that are believed to be untriggerable are an additional safety and
security measure, and must stay in the final code unless performance
considerations mandate otherwise (and lavu has several levels of asserts for
that).
No, you are just putting some easy to trigger deny of service.
Again, lading your library code with abort() is wrong.
In this specific case, you might get an impossible value out of the
library for whichever reason (broken broken broken frame?), my way you
just return an error of some kind for that frame, if it is just that
single one failing and the decoder can recover, you keep decoding just
fine. The hypothetic VLC user hears a glitch and stuff keeps going on.
Your idea is to CRASH the application. The poor user then has _NOTHING_
beside maybe a crash log.
I hope this example explains why leaving asserts in code is wrong.
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
