> In the latest 2.5.x bleeding edge bk tree, set_bit() and friends have > changed to require a long as the second parameter.
Erm, why? The comments in the 2.5.9 changelog are at best cryptic, and don't say whether for example we can still rely on bit numbering working the same. Only two arches were changed. > I didn't see an easy fix for these warnings, so patches from the authors > are greatly appreciated :) It'd be nice if the fix were just to cast everything, but it's not clear that there hasn't in fact been a change in the semantics here. If for example bit zero is now supposed to be the LSB of an N bit quantity rather than the LSB of the first byte pointed to, then this is an API-incompatible change and I might rather have seen a new/different API talking "long". (Of course if bit zero were the LSB on little-endian HW, and MSB on big-endian ... then the primary effect of this change would be adding a requirement for pointer alignment. Not that I've ever seen the bit numbering convention Linux used be written up in kerneldoc, which has been a problem in its own right. ;) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
