On 08/19/2017 12:23 AM, Eric Blake wrote: > We already have several files that knowingly require assert() > to work. While we do NOT want to encourage the use of > 'assert(side-effects)' (that is a bad practice that prevents > copy-and-paste of code to other projects that CAN disable > assertions; plus it costs unnecessary reviewer mental cycles > to remember our project policy on crippling asserts), we DO > want to send a message that anyone that disables assertions > has to tweak code in order to compile, making it obvious that > we are not going to support their efforts. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > --- > > First mentioned as an idea here: > http://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg06084.html > but I'm titling this RFC as I'm not 100% convinced we want to make > it a project-wide, rather than a per-file decision.
I think project wide is just right for what you describe: tell the people before disabling assertions you have to change the code (and preferably at least examine each usage of assert project-wide). OTOH I do think this is to some degree institutionalizing a bad practice (you say we do not want to do that, but IMHO refusing to build with NDEBUG makes only sense if we want to alter the semantic of assert so that once bad becomes acceptable). I can live with that, but I'm not happy about it. Have we considered rolling our own construct which is designed to exhibit the properties we desire? I mean, if it's about the side effects we could create something like q_assert(cond) and state that cond is evaluate exactly once (and depending on what we want to have, make the actions on !cond (calling abort(), producing a diagnostic message) compile time tweak-able or not). I assume we could then convert each usage of assert to the safe q_assert programmatically. Regards, Halil
