I will trim the discussion somewhat. Le tridi 3 germinal, an CCXXIII, Luca Barbato a écrit : > Code that can be tested and verified easily actually.
Really? So you mean that for every assert() that you replaced by something looking like error handling, you actually did manage to trigger the failure? I will state it another way: If you do not manage to produce the "assertion failed" crash, even with crafted input, crafted environment, crafted resource limits, whatever you want short of actually changing the code, then leave it alone, it is right and good. You seem to be under the misapprehension that "assert(foo)" means "I really hope that foo is true, and I would not know what to do with it if it not, so let's assume it is". It does not mean that. People who use asserts like that are wrong. Yes, people who are wrong exist. For asserts and for other things. You will find a lot of people who cast pointers all over the place, and never realize that their code is wrong because they only run it on x86, and it crashes only a few times. Shall you then remove all uses of pointers in the libav code base, just because bad programmers can not use pointers properly? Personally, I only deduce that bad programmers should stick to java. The same goes for asserts. "assert(foo)" means "I know that foo is true, but since it is a bit tricky, I write it explicitly (if it were even more tricky, I would write the proof in comments)." Writing it explicitly in the code has tons of advantages. Apart from the added safety that I already emphasized, asserts help human readers to understand the code. They also may help the compilers to better optimize it and static analyzers to be more efficient (either by silencing false positive, when the assert is actually true but the static analyzer is not smart enough to see it or by giving it a target to disprove). Feel free to track down wrong uses of asserts. But please leave the valid ones alone. Now, I must say I am a bit tired of this discussion, and I have other things planned tonight. If you are still not convinced, I can self-caricature the anti-constructive rivality: "Please, replace all asserts by untested dead code; please make avconv more bloated and less secure. We will just fix it back in FFmpeg." Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
