Messages in this thread | | | Date | Fri, 17 Oct 2008 01:16:09 +0200 | From | "Frédéric Weisbecker" <> | Subject | Re: [git pull] core kernel updates for v2.6.28 |
| |
2008/10/17 Linus Torvalds <torvalds@linux-foundation.org>: > Well, the thing is, on 32-bit x86, ptrdiff_t is "int". And on 64-bit, it's > "long". And on some (most?) other architectures, it's "long" regardless of > whether it's 32-bit or 64-bit. > > So you fixed a warnign on x86-32, but you introduced it just about > everywhere else. > > And it so happens that the old use of "%ld" was better than "%d", because > regardless of the exact type of ptrdiff_t, with gcc it is essentially > always going to be at least the same _size_ as "long". IOW, even when it's > "int", it will always print out correctly with "%ld", despite the format > warning. IOW, the type may be "wrong" from a C standards standpoint, but > it will work in practice. > > In contrast, using "%d" can actually print it out wrong, because it will > be literally the wrong physical size, not just a type issue on a C level. > So depending on calling conventions, you might end up with the upper bits > cleared, or even the wrong bits printed out. > > Using "%td" is always right, assuming the underlying printing library is > recent enough to know about it. And the kernel has known about %td for the > last three years. > > Linus
Oops you're right my fix made things worst than before. I will be aware of this %td for the future.
Thanks for the explanations Linus.
| |