lkml.org 
[lkml]   [2004]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: What policy for BUG_ON()?
From
Date
On Mon, 30 Aug 2004, 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

It comes down to the relative importance of:

i. BUG_ON(expensive_and_unneeded_debug_test())
ii. BUG_ON(something_that_must_execute())

I think case i should get priority, since then the
removal of side effects is a nice way to eliminate
the expensive code for non-debug builds.

For case ii, it's easy enough to split out the
need-to-execute code and assign results to a
variable that can be checked later. Since it is
something that must execute, you probably need
the return value anyway.

The normal expectation for non-debug builds
would be this:

#define BUG_ON(x)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2011 Jasper Spaans