To assert() or not to assert(), that is not really a question...

Ravi Pokala rpokala at freebsd.org
Mon May 28 20:07:40 UTC 2018


Interesting stuff. Thanks, phk!

-Ravi (rpokala@)

-----Original Message-----
From: Poul-Henning Kamp <phk at phk.freebsd.dk>
Date: 2018-05-28, Monday at 11:24
To: Ravi Pokala <rpokala at freebsd.org>
Cc: <arch at freebsd.org>
Subject: Re: To assert() or not to assert(), that is not really a question...

--------
In message <4427091E-3B0E-4C34-B4C6-3557DD7B55E4 at panasas.com>, Ravi Pokala writ
es:

>> 1. "Regular asserts" - things which are just plain wrong, which
>>    probably means we have a genuine bug somewhere.  Examples could
>>    be null pointers where previous checks should have ensured this
>>    not be so.  Also error situations for which there is no saner
>>    handling that killing the projcess.
>> 
>> ...
>> 
>> 3. "wrong asserts" - Internal state is messed up, program flow
>>    has taken a "impossible" branch.  A good example is the
>>    default branch of a switch on a finite input set.
>
>Hi Poul-Henning,
>
>I am in strong overall agreement with your argument. I am however
>confused as to how (1) and (3) are different; they're both irrevocably
>bad internal state.

The regular assert is assert() as we know and love it, and if it triggers
it reports the C-source of the failing condition.

The WRONG macro always triggers, and reports its string argument.

Here is a random snippet of varnish code showing both:

        /* Per specification */
        assert(sizeof vpx1_sig == 5);
        assert(sizeof vpx2_sig == 12);

        [...]
        p = req->htc->rxbuf_b;
        if (p[0] == vpx1_sig[0])
                i = vpx_proto1(wrk, req);
        else if (p[0] == vpx2_sig[0])
                i = vpx_proto2(wrk, req);
        else
                WRONG("proxy sig mismatch");


Poul-Henning

PS:

You can explore the Varnish source code here:

	https://github.com/varnishcache/varnish-cache

Asserts defined in:

	.../include/vas.h

Custom backtrace/state dump in:

	.../bin/varnishd/cache/cache_panic.c

Code coverage results:

	http://varnish-cache.org/gcov/

You may also find the void-pointer paranoia interesting:

	.../include/miniobj.h

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.




More information about the freebsd-arch mailing list