lkml.org 
[lkml]   [2012]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] utilize _Static_assert() for BUILD_BUG_ON() when the compiler supports it
Wow, it's really easy to miss parallel development on the same issue.  
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few others) back in September
(https://lkml.org/lkml/2012/9/28/1136). I've finally gotten ACKs from
maintainers with v6 of the patches (here
https://lkml.org/lkml/2012/11/20/621) and I'm just waiting for 3.8-rc1
to re-submit them. I actually submitted these patches back in June as
part of a larger patch set, but broke it apart in September (I had way
to many changes for one patch set)


On 11/07/2012 05:24 PM, Rusty Russell wrote:
> Jan Beulich<JBeulich@suse.com> writes:
>>>>> On 07.11.12 at 02:03, Rusty Russell<rusty@rustcorp.com.au> wrote:
>>>>> __COUNTER__:
>>>>> Used to make a unique id. Let's define __UNIQUE_ID(prefix) for
>>>>> this (using __COUNTER__ or __LINE__). 4.3 and above.
>>>> The fallback to __LINE__ is not necessarily correct in all cases,
>>>> namely when deep macro expansions result in two instances used
>>>> on the same source line, or a use in a header matches line number
>>>> wise a second use in another header or the source file.
>>>>
>>>> I considered to option of a fallback (and hence an abstraction in
>>>> compiler*.h) when doing this, but I didn't want to do something
>>>> that would break in perhaps vary obscure ways.
>>> I was thinking of my own code in moduleparam.h, but elfnote.h does the
>>> same trick. In both cases, it'll simply fail compile if we fallback and
>>> __LINE__ isn't unique.
>>>
>>> So again, I don't think we're going to see many uses, and no existing
>>> use will bite us.
>> That's exactly the point - we can't know (because there's no
>> guarantee there aren't - or won't be by the time it might get
>> merged - any two conflicting uses of BUILD_BUG_ON...().
> Conflicting BUILD_BUG_ON() is completely harmless: two identical
> undefines are OK. The other cases cause a compile error, and one which
> is trivial to fix, and I'm happy to fix it if it does.
>
> I've never seen a construction in the kernel which would silently break
> if __UNIQUE_ID() isn't actually unique. That makes sense, because you
> if the symbol wasn't exposed you wouldn't need a __UNIQUE_ID. And if
> it's exposed, the compiler will give an error on multiple definition.
>
> (Obviously you can't have non-static __UNIQUE_ID() because it's only
> ever unique across a single gcc compile).
I was considering __COUNTER__, but in the end, others felt that the
inconsistency could cause problems later. However, with the
__compiletime_error function attribute, the result will only be that the
actual error message emitted will be incorrect, since the first error
attribute assigned to the extern function will be used. Thus, compiling
this code:

{extern void func(void) __attribute__((error("hello")));}
{extern void func(void) __attribute__((error("goodbye"))); func();}

would result in an error with the message "hello".

>>>> #define __build_bug_on_failed(n) __build_bug_on_##n##_failed
>>>> #define _BUILD_BUG_ON(n, condition) \
>>>> do { \
>>>> extern void __compiletime_error(#condition) \
>>>> __build_bug_on_failed(n)(void); \
>>>> if (condition) __build_bug_on_failed(n)(); \
>>>> } while(0)
>> Actually, I just noticed that __linktime_error() really is a compile
>> time error when gcc supports __attribute__(__error__()), so
>> probably using that one instead of __compiletime_error() here
>> would be the cleaner approach.
>>
>> The one thing puzzling me here is that __linktime_error() gets
>> defined even if __CHECKER__ isn't defined, while
>> __compiletime_error() doesn't - an apparent inconsistency
>> between 746a2a838deec3ef86ef6b7c3edd4207b9a351aa
>> (Kosaki?) and 1399ff86f2a2bbacbbe68fa00c5f8c752b344723
>> (David?), with apparently the latter being too lax, as it only
>> introduced a use inside a !__CHECKER__ section.
> Yes, __linktime_error() makes no sense, since it's identical to
> __compiletime_error(). It's also a terrible name. Let's kill it.
Definitely. My patch set kills that sucker too.
>
> I hadn't noticed BUILD_BUG. We should fix that as discussed here, and
> simply make BUILD_BUG_ON() call it.
>
>>> Subject: __UNIQUE_ID()
>>>
>>> Jan Beulich points out __COUNTER__ (gcc 4.3 and above), so let's use
>>> that to create unique ids. This is better than __LINE__ which we use
>>> today, so provide a wrapper.
>>>
>>> Signed-off-by: Rusty Russell<rusty@rustcorp.com.au>
>> Acked-by: Jan Beulich<jbeulich@suse.com>
> Thanks,
> Rusty.
https://lkml.org/lkml/2012/9/28/1136


\
 
 \ /
  Last update: 2012-12-13 01:41    [W:0.122 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site