Wow! Amazing. I think you're missing the nut. The sizeof operator
is not sending back a wrong argument, but the variable could be
getting trashed. You also could be attempting to printk a size_t of
something big in userspace eg, the coda fs guys do a lot of printk's
of the size of stuff on the coda server. Now the server is in
userspace across the network. All kinds of things could trash the
size_t. If you silently truncate it you severly limit its usefulness
as a diagnostic aid. This has _nothing_ to do with having 4GB data
structures in your kernel.
> > Firstly, I don't think "printk" latency is a real performance
>
> It is microscopic, but why pay it for zero benefit?
Its not zero benefit, its portability, and correctness, and a
standard.
> > issue (also my patch doesn't add overhead). Secondly, I don't think
> > an extra character in the format string is a loss compared with doing
>
> same as above, but this is worse
>
> >> This is not good. Every printk() with the problem ends up with
> >> an extra character in the format string and possibly extra overhead.
> >> For what? So you can have a 5 GB structure in kernel space?
> >
> > So you can see when the top half of a 64 bit pointer has been trashed.
>
> If the top half of sizeof() gets trashed, your compiler is broken.
> The compiler will crash. You should report this to the gcc maintainers.
Not the sizeof().
> BTW, one should use %p for pointers, not %zd.
This isn't about printing pointers (I know about %p). Its about
size_t.
> If it is the explicit cast you object to, you can try this hack:
> #define sizeof (unsigned)sizeof
Great, now my Alpha is restricted to the size_t of intel. Very
nice...
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/