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

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 08/22/2017 06:19 AM, Halil Pasic wrote:
>
>> 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've thought about it, and it may have even been discussed on the list
> perhaps (although I didn't go searching to verify).
>
>> 
>> 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.
>
> I'd prefer that if we are going to introduce our own construct that
> always evaluates side effects, and only has a compile-time switch on
> whether to abort() or (foolishly) plow on, that we name it something
> without 'assert' in the name, so that reviewers don't have to be
> confused about remembering which variant evaluates side effects.  Maybe:
>
> q_verify(cond)
>
> is a good name, which performs the side effects of 'cond' no matter
> what, but also allows us to abort() if cond fails vs. ignore the
> failure; perhaps where we make a compile-time decision between the two
> behaviors as a configure --enable-FOO flag.
>
> Converting all existing assert() and g_assert() to q_verify() should be
> fairly simple, if we like the idea.

About as simple as expanding tabs.

CODING_STYLE demands spaces rather than tabs since 2009.  455 out of
3542 C source files have tabs.  Only a minority of them is imported from
other projects and thus exempt from CODING_STYLE.

I vote for frying bigger fish.

I also vote for using standard C when standard C is servicable.