Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS

From: Roman Zippel
Date: Thu Aug 05 2004 - 13:35:12 EST


Hi,

On Thu, 5 Aug 2004, Andrew Morton wrote:

> OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > > #define next_node(n, src) __next_node((n), &(src), MAX_NUMNODES)
> > > static inline int __next_node(int n, const nodemask_t *srcp, int nbits)
> > > {
> > > - return find_next_bit(srcp->bits, nbits, n+1);
> > > + return min_t(int, nbits, find_next_bit(srcp->bits, nbits, n+1));
> > > }
> >
> > Shouldn't these use simply min()? I worry min_t() may hide the real bug...
>
> The problem is that on some architectures, find_next_bit() returns an
> unsigned long, on others it returns an int and I think some even return a
> long.

Personally I prefer to cast only one argument:

+ return min(nbits, (int)find_next_bit(srcp->bits, nbits, n+1));

If the nbits type should change, it's not as easy to miss.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/