Typedefs / gcc / HIGHMEM

From: Stephan von Krawczynski (skraw@ithnet.com)
Date: Sat Dec 08 2001 - 13:38:00 EST

Hello all,
I recently cam across a warning during compilation of kernel in
/linux/drivers/net/tulip/interrupt.c. It looks like this:
interrupt.c: In function `tulip_rx':
interrupt.c:201: warning: unsigned int format, different type arg (arg
The source in question looks like this:
printk(KERN_ERR "%s: Internal fault: The skbuff addresses "
"do not match in tulip_rx: %08x vs. %08x %p / %p.\n",
skb->head, temp);
Problem lies in tp->rx_buffers[entry].mapping which is of type
dma_addr_t is either defined as u32 (no highmem) or u64 (highmem).
u32 is unsigned int.
u64 is unsigned long long
The warning only occurs in the highmem-case. This obviously means that
gcc is not able to evaluate u64 as comparable to unsigned (long). We
can fix this by casting the value, but on the other hand there seem to
be additional issues possible, the value-comparation one line above
shows this:
if (tp->rx_buffers[entry].mapping !=
   le32_to_cpu(tp->rx_ring[entry].buffer1)) {
The first is u64, the second u32. Either the u64 value is not
required, or the statement is broken. Astonishing there is _no_
compiler warning in this line.
Has anybody looked across the kernel-code to verify if statements like
this are more widespread?
BTW, my personal opinion to "typedef unsigned int u32" is that it
should rather be "typedef unsigned long u32", but this is religious.
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/

This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:13 EST