[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18f6349cacfb6dc6fe8f1d12685ff6368c1cfbe0.camel@sipsolutions.net>
Date: Fri, 12 Oct 2018 21:45:03 +0200
From: Johannes Berg <johannes@...solutions.net>
To: linux-wireless@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, John Garry <john.garry@...wei.com>,
nbd@....name
Subject: Re: [PATCH] bitfield: use BUILD_BUG_ON_ZERO()
Umm, I really should've tested this :-)
As John points out, it can't possibly compile, e.g. because
> +#define __BF_FIELD_CHECK(_mask, _reg, _val) \
> + BUILD_BUG_ON_ZERO(!__builtin_constant_p(_mask)) + \
this isn't actually a constant expression.
This would be harmless, since e.g.
> + BUILD_BUG_ON_ZERO((_mask) == 0) + \
this already forces _mask to be a constant, but
> + BUILD_BUG_ON_ZERO(__builtin_constant_p(_val) ? \
> + ~((_mask) >> __bf_shf(_mask)) & (_val) : 0) + \
we can't actually replicate this check.
We could just remove this as well, at the expense of not getting any
warnings if you write something like
FIELD_PREP(0xf, 32);
Realistically, FIELD_PREP() is the only one that makes sense in a pure
constant context though, so we could just add __FIELD_PREP for that,
*with* all the checks. I'll send out a patch in a second that has this
and also adds __{u,le,be}{16,32,64}encode_bits().
johannes
Powered by blists - more mailing lists