Re: [PATCH] utilize _Static_assert() for BUILD_BUG_ON() when the compiler supports it

[Rusty Russell]

Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:

> On Fri, 02 Nov 2012 14:47:40 +0000
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>
>> This makes the resulting diagnostics quite a bit more useful.
>
> So asserts Jan, but to confirm it I would need to download, configure,
> build and install a different gcc version, which sounds rather a hassle.
>
> So, please show us an exmple of these diagnostics in the changelog.
>
>> --- 3.7-rc3/include/linux/bug.h
>> +++ 3.7-rc3-static-assert/include/linux/bug.h
>> @@ -27,8 +27,15 @@ struct pt_regs;
>>     result (of value 0 and type size_t), so the expression can be used
>>     e.g. in a structure initializer (or where-ever else comma expressions
>>     aren't permitted). */
>> +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
>
> This sort of logic is normally performed via the
> include/linux/compiler*.h system.  And
>
> 	grep __GNUC include/linux/*.h
>
> indicates that we've been pretty successful.  Can we do that here too?
>
> (eg: suppose the Intel compiler supports _Static_assert?)

Yeah, there are a lot of goodies here:

_Static_assert:
        We could define __ASSERT_STRUCT_FIELD(e) for this:
        #define BUILD_BUG_ON_ZERO(e) \
                sizeof(struct { __ASSERT_STRUCT_FIELD(e); })

__COUNTER__:
        Used to make a unique id.  Let's define __UNIQUE_ID(prefix) for
        this (using __COUNTER__ or __LINE__). 4.3 and above.

__compiletime_error():
        I blame Arjan for this.  It disappears if not implemented, which
        is just lazy.  BUILD_BUG_ON() does this right, and he didn't fix
        that at the time :(

I'd say we have three patches here, really:

1) Add __ASSERT_STRUCT_FIELD(e) to compiler.h
2) Add __UNIQUE_ID().
3) Use them (I can think of at least one other place for __UNIQUE_ID()).

Jan, do you want the glory?  :) If not, I'll respin.

Thanks,
Rusty.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/