Messages in this thread | | | Date | Wed, 12 Dec 2012 18:48:12 -0600 | From | Daniel Santos <> | Subject | Re: [PATCH] utilize _Static_assert() for BUILD_BUG_ON() when the compiler supports it |
| |
On 11/06/2012 03:23 AM, Jan Beulich wrote: >> 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); }) > I considered something like this too, but it wouldn't work well: The > diagnostic issued from a failed _Static_assert() would preferably > refer to the original source expression, not an already macro > expanded variant of it. That, however, precludes passing it > through multiple levels of macro expansion. Which would leave > passing e and #e to __ASSERT_STRUCT_FIELD(), but that's again > ugly as it opens the door for someone adding a use where the two > arguments don't match up. I was under the assumption that _Static_assert doesn't exist unless you are using -std=c11 or -std=gnu11, but I admit I didn't look into it much. I'm very glad it was added to the standard. IMO, it would be better to use such a feature (presuming it behaves well) when it is available but, of course, we still need the best possible functionality when it isn't.
In either case, the new BUILD_BUG_ON macro simply stringifies the condition, so it will emit an error indicating the exact expression that failed. If you pass it a macro, macro expansion will not be performed prior to stringification. > >> __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 :( > Again, the name of the macro made me not use it, as the obvious > fallback is a link time error. The only thing I would be agreeable to > is something like __buildtime_error().
Yeah, I agree, since we speak more in terms of a "build" rather than compiling. But I didn't mess with it in my patches.
> >> I'd say we have three patches here, really: >> >> 1) Add __ASSERT_STRUCT_FIELD(e) to compiler.h There are actually a number of reasons for having multiple mechanisms to break the build. For instance, BUILD_BUG_ON_ZERO is used outside of function bodies, where a compound gcc expression ({expr; expr;}) isn't permitted. >> 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. > Depending on the answers to the above (i.e. how much of it > actually would need re-doing and re-testing), it may take me > some time to get to this, but beyond that I'm fine with trying > to improve this to everyone's satisfaction. Personally, I would rather we start a cpputil.h (or some such) to encapsulate all of our preprocessor kludgery, err, I mean wizardry. There must be 14 thousand paste macros in the kernel. We could move stringify into it as well, but I suppose that's another issue.
Daniel
| |