[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121005210258.GB7362@jtriplet-mobl1>
Date: Fri, 5 Oct 2012 14:02:59 -0700
From: Josh Triplett <josh@...htriplett.org>
To: Borislav Petkov <bp@...en8.de>, danielfsantos@....net,
LKML <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...ux.intel.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Christopher Li <sparse@...isli.org>,
David Daney <david.daney@...ium.com>,
David Howells <dhowells@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Joe Perches <joe@...ches.com>,
Konstantin Khlebnikov <khlebnikov@...nvz.org>,
linux-sparse@...r.kernel.org,
Michel Lespinasse <walken@...gle.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Pavel Pisa <pisa@....felk.cvut.cz>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Steven Rostedt <rostedt@...dmis.org>,
Daniel Santos <daniel.santos@...ox.com>
Subject: Re: [PATCH v2 09/10] bug.h: Add BUILD_BUG_ON_MSG &
BUILD_BUG_INTERNAL{,2}
On Fri, Oct 05, 2012 at 10:58:58PM +0200, Borislav Petkov wrote:
> On Fri, Oct 05, 2012 at 02:42:48PM -0500, danielfsantos@....net wrote:
> > Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
> > turned enabled), except that it allows you to specify the error message
> > you want emitted as the third parameter. Under the hood, this relies on
> > BUILD_BUG_INTERNAL{,2}, which does the actual work and is pretty-much
> > identical to BUILD_BUG_ON.
> >
> > Signed-off-by: Daniel Santos <daniel.santos@...ox.com>
> > ---
> > include/linux/bug.h | 26 ++++++++++++++++++++++++++
> > 1 files changed, 26 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/bug.h b/include/linux/bug.h
> > index 1b43ea2..91bd9d5 100644
> > --- a/include/linux/bug.h
> > +++ b/include/linux/bug.h
> > @@ -16,6 +16,7 @@ struct pt_regs;
> > #define BUILD_BUG_ON_NOT_POWER_OF_2(n)
> > #define BUILD_BUG_ON_ZERO(e) (0)
> > #define BUILD_BUG_ON_NULL(e) ((void*)0)
> > +#define BUILD_BUG_ON_MSG(cond, msg) (0)
> > #define BUILD_BUG_ON(condition) (0)
> > #define BUILD_BUG() (0)
> > #else /* __CHECKER__ */
> > @@ -38,6 +39,31 @@ struct pt_regs;
> > */
> > #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
> >
> > +#define _CONCAT1(a, b) a##b
> > +#define CONCAT(a, b) _CONCAT1(a, b)
>
> Let's call the indirection _CONCAT without the "1".
>
> > +#define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
> > +
> > +#define BUILD_BUG_INTERNAL2(condition, msg, fn) \
> > + do { \
> > + extern void fn (void) __compiletime_error(msg); \
> > + __compiletime_error_fallback(condition); \
> > + if (condition) \
> > + fn(); \
> > + } while (0)
> > +
> > +#define BUILD_BUG_INTERNAL(condition, msg, fn) \
> > + BUILD_BUG_INTERNAL2(condition, msg, fn)
>
> Ditto. BUILD_BUG_INTERNAL2 should be __BUILD_BUG_INTERNAL and the one
> calling it _BUILD_BUG_INTERNAL (with one underscore).
Also, you don't need both the BUILD_BUG_INTERNAL and CONCAT/UNIQUIFY
macros. My original implementation just used the BUILD_BUG_INTERNAL
family of macros; if you'd rather rename them, by all means do so, but I
don't think you need two separate families of multiply-indirect macros.
> > +
> > +/**
> > + * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
> > + * error message.
> > + * @condition: the condition which the compiler should know is false.
> > + *
> > + * See BUILD_BUG_ON for description.
> > + */
> > +#define BUILD_BUG_ON_MSG(cond, msg) \
> > + BUILD_BUG_INTERNAL(cond, msg, UNIQUIFY(__build_bug_on_failed_))
>
> Btw, why are we adding the line at all? It is issued by gcc anyway:
>
> cc -Wall macros.c -o macros
> macros.c: In function ‘main’:
> macros.c:22:1: error: ‘__build_bug_on_failed_22’ undeclared (first use in this function)
Because without that, you end up writing multiple prototypes for the
same function (__build_bug_on_failed) with different error attributes,
and GCC will ignore all but the last error attribute it sees, even with
a scoped prototype.
- Josh Triplett
--
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