On Wed, 2008-04-02 at 17:32 +0300, Boaz Harrosh wrote:
> James Bottomley wrote:
> <snip>
> > Well, we can agree to differ on this. The camp that wants no side
> > effects for BUG_ON() does so in case they want to define it to be a nop.
> > I've always argued that having special rules for this that differ from
> > functions is asking for trouble. It's also easy to preserve the side
> > effects by making the compile out do this:
> >
> > #define BUG_ON(x) (void)(x)
> >
> > That lets the compiler process the side effects and discard the result.
> > This basically means the rules for BUG_ON() arguments are identical to
> > the rules for function arguments ... I think that's consonant with the
> > principle of least surprise.
> >
>
> The Kernel seems to agree with you:
> #define BUG_ON(condition) do { if (condition) ; } while(0)
>
> what should we do with stuff like
> BUG_ON(check_foo_valid());
> which is time consuming and should not run on production machines
create a separate CONFIG_FOO_DEBUG flag ... BUG_ON is designed to
operate as assertion checks on all systems ... including production
ones. In fact, I've never really agreed with the need to compile it out
in the first place. Extra and time consuming debugging should be
controlled by a config (or runtime, which is nice because you can turn
it on if there's a problem) variable.
> should we directly use:
> #ifdef CONFIG_BUG
> or is there some other facility for that?
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
