All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Marques <pmarques@grupopie.com>
To: Jens Axboe <axboe@suse.de>
Cc: Arjan van de Ven <arjanv@redhat.com>,
	Adrian Bunk <bunk@fs.tum.de>, Linus Torvalds <torvalds@osdl.org>,
	Andrew Morton <akpm@osdl.org>, Matt Mackall <mpm@selenic.com>,
	linux-kernel@vger.kernel.org
Subject: Re: What policy for BUG_ON()?
Date: Tue, 31 Aug 2004 12:14:25 +0100	[thread overview]
Message-ID: <41345D91.2050202@grupopie.com> (raw)
In-Reply-To: <20040831062815.GA2312@suse.de>

Jens Axboe wrote:
> On Mon, Aug 30 2004, Arjan van de Ven wrote:
> 
>>On Mon, 2004-08-30 at 22:15, Adrian Bunk wrote:
>>
>>>Let me try to summarize the different options regarding BUG_ON, 
>>>concerning whether the argument to BUG_ON might contain side effects, 
>>>and whether it should be allowed in some "do this only if you _really_ 
>>>know what you are doing" situations to let BUG_ON do nothing.
>>>
>>>Options:
>>>1. BUG_ON must not be defined to do nothing
>>>1a. side effects are allowed in the argument of BUG_ON
>>>1b. side effects are not allowed in the argument of BUG_ON
>>>2. BUG_ON is allowed to be defined to do nothing
>>>2a. side effects are allowed in the argument of BUG_ON
>>>2b. side effects are not allowed in the argument of BUG_ON
>>
>>since you quoted me earlier my 2 cents:
>>1) I would prefer BUG_ON() arguments to not have side effects; its just 
>>cleaner that way. (similar to assert)
>>
>>2) if one wants to compiel out BUG_ON, I rather alias it to panic() than
>>to nothing.
> 
> 
> I agree completely with that.

This would mean that the condition would still have to be
tested which kind of defeats the purpose of removing the
BUG_ON in the first place, doesn't it?

-- 
Paulo Marques - www.grupopie.com

To err is human, but to really foul things up requires a computer.
Farmers' Almanac, 1978

  reply	other threads:[~2004-08-31 11:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-30 20:15 What policy for BUG_ON()? Adrian Bunk
2004-08-30 20:22 ` Arjan van de Ven
2004-08-31  6:28   ` Jens Axboe
2004-08-31 11:14     ` Paulo Marques [this message]
2004-08-31  0:25 ` Linus Torvalds
2004-08-31 11:28   ` Adrian Bunk
  -- strict thread matches above, loose matches on Subject: below --
2004-08-31 15:06 Albert Cahalan
2004-08-31 16:52 ` Linus Torvalds
2004-08-31 17:39   ` Albert Cahalan
2004-08-31 21:30     ` Kyle Moffett
2004-08-31 22:16       ` Michael Buesch
2004-08-31 23:32         ` Kyle Moffett

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=41345D91.2050202@grupopie.com \
    --to=pmarques@grupopie.com \
    --cc=akpm@osdl.org \
    --cc=arjanv@redhat.com \
    --cc=axboe@suse.de \
    --cc=bunk@fs.tum.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=torvalds@osdl.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.