lkml.org 
[lkml]   [2004]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: What policy for BUG_ON()?
    From
    Date
    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 comes down to the relative importance of:

    i. BUG_ON(expensive_and_unneeded_debug_test())
    ii. BUG_ON(something_that_must_execute())

    I think case i should get priority, since then the
    removal of side effects is a nice way to eliminate
    the expensive code for non-debug builds.

    For case ii, it's easy enough to split out the
    need-to-execute code and assign results to a
    variable that can be checked later. Since it is
    something that must execute, you probably need
    the return value anyway.

    The normal expectation for non-debug builds
    would be this:

    #define BUG_ON(x)


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

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.032 / U:0.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site