lkml.org 
[lkml]   [2012]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 09/10] bug.h: Add BUILD_BUG_ON_MSG & BUILD_BUG_INTERNAL{,2}
    On 10/05/2012 04:02 PM, Josh Triplett wrote:
    > On Fri, Oct 05, 2012 at 10:58:58PM +0200, Borislav Petkov wrote:
    >> On Fri, Oct 05, 2012 at 02:42:48PM -0500, danielfsantos@att.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@pobox.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".

    No problem, naming conventions are good! :)

    >>
    >>> +#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.

    Yeah, I was thinking in terms of reusable macros. I'm kinda thinking the
    kernel needs a header just for handy little macros, like concat,
    uniquify, the
    IS_EMPTY and IF_EMPTY macros of mine in rbtree.h, etc. There is a
    stringify.h
    that just contains a __stringify macro. But here, it's just verbose, so
    I'll
    change it back to how you had it.

    >>> +
    >>> +/**
    >>> + * 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.

    Yeah, this is part of the trick to get non-existent functions with different
    messages on their error attributes, so that each BUILD_BUG_ON-type macro can
    have more helpful text in its error message. I don't know what's in your
    macros.c, but it should have given you a much more shiny error message.

    Daniel
    --
    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: 2012-10-06 07:01    [W:3.204 / U:0.748 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site