Re: call for API review: new bitstring functions

[Jeffrey Hsu <hsu@xxxxxxxxxxx>]

  > 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.

							Jeffrey