Re: [Qemu-devel] [RFC PATCH] osdep.h: Prohibit disabling assert() in supported builds

[Halil Pasic]

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 <address@hidden>
> ---
> 
> 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