sys/bitfield: add support for bit-wise bitfield operations

[benpicco]

Contribution description

This adds support for bit-wise (AND, OR, XOR, NOT) operations to bitfields.

Testing procedure

The tests-bitfield unit test has been extended with the new operations.

Issues/PRs references

[OlegHahm]

I think we should add a @pre stating that the size for a, b, and c must be greater than len.

Also, I would rephrase to something like

  * @param[in]     len   The number of bytes to which the operation is applied.

[benpicco]

the size for a, b, and c must be greater than len.

Shouldn't it be at least len?
I assumed one would typically run the operation on the whole bitfield, not arbitrary byte-sized chunks.

[OlegHahm]

Sure, it should just be documented exactly to make sure that it is the responsibility of the caller to check these preconditions.

[benpicco]

I feel like this is stating the obvious, but there you go

[kfessel]

Exiting functions/macros use size as the number of bits.

There already is an operation int bf_get_unset(uint8_t field[], int size); which has a size parameter, they should all use the same type - seems size_t would be correct.

bitfield.h also seems to miss some kind of initialization illustrated by the example l202 and l203

[kaspar030]

There already is an operation int bf_get_unset(uint8_t field[], int size); which has a size parameter, they should all use the same type - seems size_t would be correct.

I agree on this. Also, using bits vs. bytes doesn't fail as horrible as if someone supplies the number of bits as bytes argument. (does this sentence make sense?)

[kaspar030]

I'd like to see a line or two on the unused bits of a bitfield and how they are affected by the ops. I mean, a "bitfield" of 10 bits uses 2 bytes of storage. the unused 6 bits will get modified by the current and/or/xor implementations. That is fine IMO, but should be documented.

[kfessel]

murdock test are sufficient in this case, and murdock is green.