[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200910201142.34006.rusty@rustcorp.com.au>
Date: Tue, 20 Oct 2009 11:42:32 +1030
From: Rusty Russell <rusty@...tcorp.com.au>
To: Hollis Blanchard <hollisb@...ibm.com>
Cc: Jan Beulich <JBeulich@...ell.com>, sfr@...b.auug.org.au,
akpm@...ux-foundation.org, linuxppc-dev@...ts.ozlabs.org,
kvm-ppc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-next@...r.kernel.org
Subject: Re: linux-next: tree build failure
On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote:
> On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
> > My perspective is that it just uncovered already existing brokenness.
>
> Sorry, I thought it was clear, but to be more explicit: I propose the
> following patch, which replaces the current BUILD_BUG_ON implementation
> with Rusty's version.
OK, I switched my brain back on. Yeah, I agree: we may still want
BUILD_OR_RUNTIME_BUG_ON one day, but I like this.
It's just missing the giant comment that it needs :)
/**
* BUILD_BUG_ON - break compile if a condition is true.
* @cond: the condition which the compiler should know is false.
*
* If you have some code which relies on certain constants being equal, or
* other compile-time-evaluated condition, you should use BUILD_BUG_ON to
* detect if someone changes it.
*
* The implementation uses gcc's reluctance to create a negative array, but
* gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
* to inline functions). So as a fallback we use the optimizer; if it can't
* prove the condition is false, it will cause a link error on the undefined
* "__build_bug_on_failed". This error is less neat, and can be harder to
* track down.
*/
Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists