On 19/04/16 13:26, Anton Khirnov wrote: > Quoting Luca Barbato (2016-04-18 20:55:24) >> On 18/04/16 20:51, Anton Khirnov wrote: >>> I don't like this. We already have av_assert for exactly this purpose. >> >> I do not like av_assert0 and I want an easy way to enable/disable the >> assert()s. > > What exactly is wrong with av_assert0? It is exists exactly for this > purpose.
Because who uses them way too often puts them after the state it should guard got inconsistent, certifying that something happened, not preventing it. Its purpose is dangerous, since putting possibly-reachable abort() in a library should be an exception not the norm (for such cases __builtin_unreachable() should be used when available). > Besides, I don't see why would one every need to disable asserts. IMO > they should always be enabled. Disabled code tends to rot. Because that's the way the fine manual tells you to use assert and because I do not want code that should not execute in my release builds and so other people. assert() is used to document that something never happens and you should enable them only when developing so if you refactor the code you safeguard that assumption you made stay valid. The original idea of av_assertN() was to have a simple way to enable/disable asserts that are: 0 - on cold paths so having them on always wouldn't have a big speed impact, if any 1 - in places it would have a small impact 2 - in tight loops, killing all the performance Ideally I'd like to have --enable-assert=N and set from configure the ASSERT_LEVEL to make easier enable/disable them. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
