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
4)
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",
dev->name,
le32_to_cpu(tp->rx_ring[entry].buffer1),
tp->rx_buffers[entry].mapping,
skb->head, temp);
Problem lies in tp->rx_buffers[entry].mapping which is of type
dma_addr_t.
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.
Regards,
Stephan
Followup to: <[email protected]>
By author: Stephan von Krawczynski <[email protected]>
In newsgroup: linux.dev.kernel
>
> 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.
>
Why should there be? The u32 value gets promoted to u64 before the
comparison is done.
> BTW, my personal opinion to "typedef unsigned int u32" is that it
> should rather be "typedef unsigned long u32", but this is religious.
I see you have a background in environments where you move between 16-
and 32-bit machines. Guess what, in Linux the major movement is
between 32- and 64-bit machines, and "unsigned int" is consistent,
whereas "unsigned long" isn't (long is 32 bits on 32-bit machines, 64
bits on 64-bit machines.)
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
> > 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.
> >
>
> Why should there be? The u32 value gets promoted to u64 before the
> comparison is done.
Yes, ok, you're right. This was not a well thought out statement.
Anyway the problem with printf statement stays. It is obviously
confused by a unsigned long long and "%08x". How would you fix this?
Downcasting to u32?
> > BTW, my personal opinion to "typedef unsigned int u32" is that it
> > should rather be "typedef unsigned long u32", but this is
religious.
>
> I see you have a background in environments where you move between
16-
> and 32-bit machines. Guess what, in Linux the major movement is
> between 32- and 64-bit machines, and "unsigned int" is consistent,
> whereas "unsigned long" isn't (long is 32 bits on 32-bit machines,
64
> bits on 64-bit machines.)
Ha, I always wondered what this u64 is all about :-)
Honestly, this whole datatyping is gone completely mad since the 16-32
bit change. In my opinion
byte is 8 bit
short is 16 bit
long is 32 bit
<callwhatyouwant> is 64 bit (I propose long2 for expression of bitsize
long * 2).
<callwhatyouwant2> is 128 bit (Ha, right I would call it long4)
char is the standard representation of chars in the corresponding
environment, currently sizeof(byte).
int is the same and should move from 16 bit to 32 bit to 64 bit
depending on the machine. I mean whats the use of an int register in a
64bit environment, when datatype int is only of size 32 bit? This is
_shit_.
How do you call a 64 bit datatype in a 128 bit environment? According
to your / the worlds current terminology long will then be 128 bit and
int will (ridiculously) still be 32 bit. It will be pretty interesting
to hear people talking about integer registers and people writing
portable applications do #define int long ... A wait this will break
your #typedef unsigned int u32 story :-)
Writing portable applications can be easily done by using "meta"
datatype char/int/etc., whereas machine dependant coding could be done
by byte/short/long/long2/etc.
This is completely consistent as it _never_ changes.
Now you have an _additional_ layer where you call the stuff
u8/u16/u32/u64, which I find still ok, but you can then completely
shoot long/short/byte.
But, in fact, this is more a discussion for the RMS-world than for
L-world :-)
Regards,
Stephan
Stephan von Krawczynski wrote:
>>
>>Why should there be? The u32 value gets promoted to u64 before the
>>comparison is done.
>>
>
> Yes, ok, you're right. This was not a well thought out statement.
> Anyway the problem with printf statement stays. It is obviously
> confused by a unsigned long long and "%08x". How would you fix this?
> Downcasting to u32?
>
Either that or change it to %016llx or something like that.
>
> Ha, I always wondered what this u64 is all about :-)
> Honestly, this whole datatyping is gone completely mad since the 16-32
> bit change. In my opinion
> byte is 8 bit
> short is 16 bit
> long is 32 bit
> <callwhatyouwant> is 64 bit (I propose long2 for expression of bitsize
> long * 2).
> <callwhatyouwant2> is 128 bit (Ha, right I would call it long4)
>
Well, you're wrong.
> How do you call a 64 bit datatype in a 128 bit environment? According
> to your / the worlds current terminology long will then be 128 bit and
> int will (ridiculously) still be 32 bit. It will be pretty interesting
> to hear people talking about integer registers and people writing
> portable applications do #define int long ... A wait this will break
> your #typedef unsigned int u32 story :-)
int64_t. See the C99 standard.
-hpa
> Ha, I always wondered what this u64 is all about :-)
> Honestly, this whole datatyping is gone completely mad since the 16-32
> bit change. In my opinion
> byte is 8 bit
> short is 16 bit
> long is 32 bit
> <callwhatyouwant> is 64 bit (I propose long2 for expression of bitsize
> long * 2).
> <callwhatyouwant2> is 128 bit (Ha, right I would call it long4)
There's the bit types:
u_int8_t (unsigned char)
u_int16_t (unsigned short int)
...
int8_t (signed char)
int16_t (signed short int)
...
size_t and register_t
If I understand these correctly, size_t is the size of a pointer
(ptrdiff_t on linux?) and register_t is signed size_t.
These are common along GNU and BSD systems,
just #ifdef __BIT_TYPES_DEFINED__
For porting issues, many Win32 headers have them as now,
and for DOS16 and DOS32 they're easy.
> char is the standard representation of chars in the corresponding
> environment, currently sizeof(byte).
> int is the same and should move from 16 bit to 32 bit to 64 bit
> depending on the machine. I mean whats the use of an int register in a
> 64bit environment, when datatype int is only of size 32 bit? This is
> _shit_.
ACK.
-mirabilos
> int64_t. See the C99 standard.
Do you have an URI for that standard?
Text or HTML, if possible... it's easier to read raw.
Thanks
[MOc]cda*mirabilos wrote:
>>int64_t. See the C99 standard.
>
> Do you have an URI for that standard?
> Text or HTML, if possible... it's easier to read raw.
> Thanks
>
Sorry, it costs money. It's available for a not too unreasonable of a
fee (USD 18) in PDF format from
http://webstore.ansi.org/ansidocstore/dept.asp
Look for ISO/IEC 9899-1999.
-hpa
Hi mirabilos :))
>> int64_t. See the C99 standard.
>Do you have an URI for that standard?
You must buy it from ISO :(((
Ra?l