Re: What policy for BUG_ON()?

From: Adrian Bunk (bunk_at_fs.tum.de)
Date: 08/31/04

  • Next message: Stuart Young: "2.6.9-rc1-mm2 : Recursive Kconfig dependency"
    Date:	Tue, 31 Aug 2004 13:28:34 +0200
    To: Linus Torvalds <torvalds@osdl.org>
    
    

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

  • Next message: Stuart Young: "2.6.9-rc1-mm2 : Recursive Kconfig dependency"

    Relevant Pages

    • Re: Exporting symbols between modules
      ... Hi Sergio, ... > I compile it and install without any problem. ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [2.6 patch] x86_64: kill stale mtrr_centaur_report_mcr
      ... > way to disable specific CPUs in there. ... I haven't tried to compile it, but OTOH I haven't yet found which dirty ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: building 2.4.31 for a non-smp system
      ... > I guess I could simply compile with CONFIG_SMP, ... There had been need of rain for many days. ... "Only a promise," Lao Er said. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: RFC: [2.6 patch] better i386 CPU selection
      ... if you compile a module with ... And you should need a "modprobe -f" if the bitmask in the module differs ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: What policy for BUG_ON()?
      ... > should become documented policy. ... I'd suggest we strongly discourage side-effects in BUG_ON. ... if somebody wants to compile without debugging. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)