On Thu, 14 Nov 2024 at 02:23, Philipp Reisner
<philipp.reisner@xxxxxxxxxx> wrote:
>
> compiler.h defines __must_be_array() and __must_be_cstr() and both
> expand to BUILD_BUG_ON_ZERO(). build_bug.h defines BUILD_BUG_ON_ZERO().
> So far compiler.h lacks to include build_bug.h.
The bug is real, but..
> Fix compiler.h by including build_bug.h. With that compiler.h and
> build_bug.h depend on each other.
I hate how compiler.h would include build_bug.h, which - on the very
first line - then in turn includes compiler.h.
Does it *work*? Yes. The standard include guards stop the thing from
recursing, and both headers only do create pre-processor defines, so
the dependencies aren't ordered, but it's really really ugly to have
these kinds of circular includes.
I think a better fix would be to not use BUILD_BUG_ON_ZERO() at all,
but just use _Static_assert() directly here, to make
<linux/compiler.h> be more self-sufficient.
The gcc docs say that __builtin_types_compatible_p() and
__builtin_has_attribute() both return an integer constant expression,
so that should be fine (the advantage of BUILD_BUG_ON_ZERO() is that
it works in some contexts that aren't necessarily technically integer
constant expressions - as long as they just evaluate to a constant).
We historically used to avoid _Static_assert(), but that was for
historical reasons (ie it's one of those things that didn't exist back
in the day..)
Hmm?
Linus
