From: josh@joshtriplett.org
To: Bart Van Assche <bvanassche@acm.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bug: Fix CONFIG_BUG=n BUG_ON()
Date: Thu, 19 Jun 2014 11:12:01 -0700 [thread overview]
Message-ID: <20140619181201.GA15963@cloud> (raw)
In-Reply-To: <53A3232E.4080601@acm.org>
On Thu, Jun 19, 2014 at 07:51:42PM +0200, Bart Van Assche wrote:
> On 06/19/14 19:21, josh@joshtriplett.org wrote:
> > That's exactly what BUG_ON becomes if CONFIG_BUG=y, and that
> > significantly increases kernel size; if you want that, set CONFIG_BUG=y.
> > BUG_ON should continue to compile to nothing if CONFIG_BUG=n, or
> > CONFIG_BUG=n has no reason to exist.
>
> Hello Josh,
>
> I wasn't aware that the current behavior of BUG_ON() with CONFIG_BUG=n
> was intentional. The reason I started looking into this is because
> different compiler warnings are generated for code with BUG_ON(1)
> statements when building against a kernel with CONFIG_BUG=y or
> CONFIG_BUG=n. There is an easy alternative though: changing BUG_ON(1)
> into BUG() in my code.
You should definitely never use BUG_ON(1); use BUG() if you want to say
"this (and the code after it) should never be reached". That should
also avoid the compiler warnings.
If you encounter any compiler warnings caused by CONFIG_BUG=n that go
away with CONFIG_BUG=y, please do report them; those should get fixed.
- Josh Triplett
prev parent reply other threads:[~2014-06-19 18:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-19 13:28 [PATCH] bug: Fix CONFIG_BUG=n BUG_ON() Bart Van Assche
2014-06-19 15:22 ` Josh Triplett
2014-06-19 17:00 ` Arnd Bergmann
2014-06-19 17:21 ` josh
2014-06-19 17:51 ` Bart Van Assche
2014-06-19 18:12 ` josh [this message]
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=20140619181201.GA15963@cloud \
--to=josh@joshtriplett.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox