Messages in this thread | | | Date | Sat, 15 Mar 2003 22:51:20 +0100 (MET) | From | Geert Uytterhoeven <> | Subject | Re: bitmaps/bitops |
| |
On Sat, 15 Mar 2003, Randy.Dunlap wrote: > Not picking on this code, but as an example: > > drivers/ieee1394/ieee1394_transactions.c, line 152 (in 2.5.64), > uses: test_and_set_bit(bit_number, tp->pool), > > where tp->pool is declared by using a DECLARE_BITMAP(), like so: > struct hpsb_tlabel_pool { > DECLARE_BITMAP(pool, 64); > > That makes sense (at least to me), but gcc complains about the > type of <pool> when used in test_and_set_bit(): > drivers/ieee1394/ieee1394_transactions.c:152: warning: passing arg 2 of > `test_and_set_bit' from incompatible pointer type > > Is this an error, a bug, a nuisance, or just another "ignore gcc 2.96" > problem? > > For reference, DECLARE_BITMAP() generates an array of unsigned longs: > #define DECLARE_BITMAP(name,bits) \ > unsigned long name[BITS_TO_LONGS(bits)] > but the prototype for test_and_set_bit() depends on $(ARCH), and it's > not consistent, with the second arg (bitmap address) being one of: > volatile void * > void * > volatile unsigned long * > > > If there's (kernel) surgery required here, unless it's trivial, I think > that I'd leave it for early 2.7.
Bitops operate on long. Architectures for which it really matters have used `unsigned long *' in there function signatures since quite some time.
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |