Re: What policy for BUG_ON()?

[Linus Torvalds]

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 would be good if there was a decision which of the four choices 
> should become documented policy.

I'd suggest we strongly discourage side-effects in BUG_ON(). 

That said, it might be safest to just go for 1b - we make side-effects of 
BUG_ON() be _documented_ as a bug, but just for safety, I'd suggest doing

	#define BUG_ON(x) (void)(x)

anyway, if somebody wants to compile without debugging. That will still 
make the side-effects happen if somebody has them (and if there are none, 
the compiler will not generate any code anyway).

In other words: nobody should _depend_ on the side effects, and we should 
flame people who have them. A quick grep shows this:

	mm/slab.c:      BUG_ON(spin_trylock(&cachep->spinlock));

which makes no real sense - it looks like slab really wants to use 
"spin_is_locked()".

I could make some sparse extension that warns about side effects. I 
already calculate the "side-effectiveness" of an expression for other 
reasons..

		Linus
-
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/