Re: What policy for BUG_ON()?
From: Adrian Bunk
Date: Tue Aug 31 2004 - 06:30:25 EST
On Mon, Aug 30, 2004 at 05:25:52PM -0700, Linus Torvalds wrote:
>
>
> 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).
>...
You say 1b but describe 2b...
The difference between 1b and 2b is that a patch to
#define BUG_ON(x) (void)(x)
with an own option under EMBEDDED might be accepted into the kernel
with 2b, but not with 1b.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
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/