DragonFly kernel List (threaded) for 2004-01
Re: call for API review: new bitstring functions
> If your functions are roughly
> equivalent to the ones already in the bitstring API, just with a
> different (more efficient) style of argument and return value handling,
> then they should be made part of the API.
The semantics and functionality of the new functions are different
from the existing functions in the bitstring API. The new functions
find the first and last bit set in a range of bits. The closest
function to that in the bitstring API is bit_ffs, which doesn't allow for
specifying a starting bit and only searches in the forward direction.
It also makes the mistake of requiring a pointer to the return value
instead of just returning the result.
The problems with incorporating the new functions in the antiquidated
bitstring API are
- We'd have to follow the legacy convention of void functions
taking a pointer to the return result to be consistent
with the existing functions. Since the new functions
are implemented as functions and not macros, having
to using macro argument passing style is especially
hard to swallow.
- We'd have to name it something obscure like bit_rffs and bit_rfls
to preserve consistency with the existing naming convention.
I am reminded of Ken Thompson's reply at his Turing award acceptance
ceremony, when asked what he'd do differently about Unix, he replied
he'd spell "creat" with an "e". Now that compilers and linkers
don't have a short limit on symbol names, naming new functions
after instructions from an obsolete computer architecture seems
like bad practice.
If we make the new routines static to the one file that uses them, then
it's not an API issue anymore. Also, I just discovered an alternative
way to do what I want without using bitmaps, so this problem may be moot
from that regard anyways.