[ovs-dev] [PATCH 07/17] util: New function bitwise_scan().

YAMAMOTO Takashi yamamoto at valinux.co.jp
Mon Sep 29 23:12:11 UTC 2014


> On Wed, Sep 24, 2014 at 10:33:21AM +0900, YAMAMOTO Takashi wrote:
>> > This will acquire its first user in an upcoming commit.
>> > 
>> > This implementation is not optimized at all but it doesn't matter for the
>> > purpose for which I intend to initially use it.
>> > 
>> > Signed-off-by: Ben Pfaff <blp at nicira.com>
>> > ---
>> >  lib/util.c | 29 +++++++++++++++++++++++++++++
>> >  lib/util.h |  2 ++
>> >  2 files changed, 31 insertions(+)
>> > 
>> > diff --git a/lib/util.c b/lib/util.c
>> > index f3e47b1..01e8a0e 100644
>> > --- a/lib/util.c
>> > +++ b/lib/util.c
>> > @@ -1273,6 +1273,35 @@ bitwise_is_all_zeros(const void *p_, unsigned int len, unsigned int ofs,
>> >      return true;
>> >  }
>> >  
>> > +/* Scans the bits in 'p' that have bit offsets 'start' through 'end'
>> > + * (inclusive) for the first bit with value 'target'.  If one is found, returns
>> > + * its offset, otherwise 'end'.  'p' is 'len' bytes long.
>> > + *
>> > + * If you consider all of 'p' to be a single unsigned integer in network byte
>> > + * order, then bit N is the bit with value 2**N.  That is, bit 0 is the bit
>> > + * with value 1 in p[len - 1], bit 1 is the bit with value 2, bit 2 is the bit
>> > + * with value 4, ..., bit 8 is the bit with value 1 in p[len - 2], and so on.
>> > + *
>> > + * Required invariant:
>> > + *   start <= end
>> > + */
>> > +unsigned int
>> > +bitwise_scan(const void *p_, unsigned int len, bool target, unsigned int start,
>> > +             unsigned int end)
>> > +{
>> > +    const uint8_t *p = p_;
>> > +    unsigned int ofs;
>> > +
>> > +    for (ofs = start; ofs < end; ofs++) {
>> > +        bool bit = (p[len - (ofs / 8 + 1)] & (1u << (ofs % 8))) != 0;
>> 
>> != 0 seems redundant because converting to c99 bool has the same semantics.
>> otherwise looks good to me.
> 
> I agree it's redundant.  I tend to include this kind of thing anyway
> in case OVS ever gets ported to a compiler that lacks C99 bool.  With
> such a compiler, one usually typedefs bool to char, and conversion to
> char will lose any 1-bit above bits 0...7, which could cause really
> subtle problems.  And with a compiler that does have C99 bool, I
> imagine that the extra != 0 is harmless.

it makes sense.

> 
> Oh, I see that I even mentioned this in CodingStyle:
> 
>     * bool and <stdbool.h>, but don't assume that bool or _Bool can
>       only take on the values 0 or 1, because this behavior can't be
>       simulated on C89 compilers.

i wasn't aware of the style.  thanks.
however i think the assumption here is a little different.
i sent CodingStyle patch for that.

YAMAMOTO Takashi

> 
>> Acked-by: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
> 
> Thanks!



More information about the dev mailing list