[lkml]   [2003]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [W:0.032 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site