Re: find_next_bit return type

[William Lee Irwin III <wli@holomorphy.com>]

On Sat, Jul 31, 2004 at 11:24:34PM -0700, Andrew Morton wrote:
> Seems that several 64-bit architectures are returning longs from
> find_next_bit(), find_next_zero_bit(), etc.  x86 returns an int.  wli sent
> me a patch which does
> 	return min(NR_CPUS, find_first_bit(srcp->bits, nbits));
> so these architectures now get a zillion warnings.
> We should be consistent here.  Is there any reason why these functions
> cannot return integers?

Not in particular, no. I'd sort of like 64-bit arches to keep their
natural wordsize as the return value as davem pointed out sign
extensions, conversions, etc. are overheads there.

To address this without a negative impact on 64-bit architectures and
to have the least code impact possible, I'd recommend the following.

(sparc32 obviously doesn't care about this issue either way)


-- wli

Index: hotplug-2.6.8-rc2/include/linux/cpumask.h
===================================================================
--- hotplug-2.6.8-rc2.orig/include/linux/cpumask.h	2004-07-29 04:44:59.000000000 -0700
+++ hotplug-2.6.8-rc2/include/linux/cpumask.h	2004-08-01 04:32:56.572244384 -0700
@@ -207,13 +207,13 @@
 #define first_cpu(src) __first_cpu(&(src), NR_CPUS)
 static inline int __first_cpu(const cpumask_t *srcp, int nbits)
 {
-	return find_first_bit(srcp->bits, nbits);
+	return min_t(int, NR_CPUS, find_first_bit(srcp->bits, nbits));
 }
 
 #define next_cpu(n, src) __next_cpu((n), &(src), NR_CPUS)
 static inline int __next_cpu(int n, const cpumask_t *srcp, int nbits)
 {
-	return find_next_bit(srcp->bits, nbits, n+1);
+	return min_t(int, NR_CPUS, find_next_bit(srcp->bits, nbits, n+1));
 }
 
 #define cpumask_of_cpu(cpu)						\