Re: What policy for BUG_ON()?

[Albert Cahalan]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/