Re: What policy for BUG_ON()?

[Albert Cahalan]

On Tue, 2004-08-31 at 12:52, Linus Torvalds wrote:
> On Tue, 31 Aug 2004, Albert Cahalan wrote:
> > 
> > The normal expectation for non-debug builds
> > would be this:
> > 
> > #define BUG_ON(x)
> 
> No, this is bad, for one big reason: it generates compiler
> warnings if 'x' happens to be the only thing that uses some value.
...
> This is generally why you should have macros like this not
> become empty, but become something that the compiler can
> compile away. Which is why I'd much rather see
> 
> 	#define BUG_ON(x) (void)(x)
> 
> regardless of any side-effect issues - it's a way to let the
> compiler optimize the thing away, but still show that
> something was used at least "conceptually"..

Expensive function calls won't get optimized away unless you
mark them __attribute__((__const__)) or __attribute__((__pure__)).
(perhaps that should be encouraged)

Then of course the compiler must assume that the function
really needed the arguments it was passed, and that it
might have modified memory, and so on.

Eh, how about a BUG_ON_WITH_SIDE_EFFECT() macro?


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