From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: BUG_ON() vs ASSERT()
Date: Tue, 13 Sep 2016 13:24:59 +0000 [thread overview]
Message-ID: <c0a911505ddb403ca48e137a57d94db7@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <57D6E49D020000780010E24F@prv-mh.provo.novell.com>
> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 12 September 2016 16:24
> To: xen-devel <xen-devel@lists.xenproject.org>
> Subject: [Xen-devel] BUG_ON() vs ASSERT()
>
> All,
>
> in
> https://lists.xenproject.org/archives/html/xen-devel/2016-
> 09/msg01201.html
> and
> https://lists.xenproject.org/archives/html/xen-devel/2016-
> 09/msg01210.html
> Andrew basically suggests that we should switch away from using
> ASSERT() and over to BUG_ON() in perhaps quite broad a set of cases. And
> honestly I'm not convinced of this: We've been adding quite a few ASSERT()s
> over the last years with the aim of doing sanity checking in debug builds,
> without adding overhead to non- debug builds. I can certainly see possible
> cases where using
> BUG_ON() to prevent further possible damage is appropriate, but I don't
> think we should overdo here.
>
> Thanks for other's opinions,
If there's a situation where code can survive a 'should not happen' then an ASSERT is good to catch the 'should not happen' when debugging, but being compiled out in production is fine. If the code is definitely not going to survive a 'should not happen' then I think a BUG_ON at the earliest opportunity is a good thing because it makes post mortem diagnosis much easier. Clearly this does have to be balanced against the cost of calculation of the subject of the BUG_ON though.
Paul
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-09-13 13:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-12 15:23 BUG_ON() vs ASSERT() Jan Beulich
2016-09-13 13:10 ` Konrad Rzeszutek Wilk
2016-09-13 13:46 ` Mihai Donțu
2016-09-13 18:25 ` Andrew Cooper
2016-09-14 17:01 ` Mihai Donțu
2016-09-13 13:24 ` Paul Durrant [this message]
2016-09-13 18:16 ` Andrew Cooper
2016-09-14 8:35 ` George Dunlap
2016-09-14 9:11 ` Andrew Cooper
2016-09-14 9:26 ` Sander Eikelenboom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c0a911505ddb403ca48e137a57d94db7@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.