linux-kernel - Re: [git pull] core kernel updates for v2.6.28

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Oct 2008 15:57:04 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Frédéric Weisbecker <fweisbec@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Kumar Gala <galak@...nel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Becky Bruce <becky.bruce@...escale.com>
Subject: Re: [git pull] core kernel updates for v2.6.28

On Fri, 17 Oct 2008, Frédéric Weisbecker wrote:
>
> 2008/10/17 Linus Torvalds <torvalds@...ux-foundation.org>:
> > The fact is, that second argument was a "ptrdiff_t", which is neither
> > "int" nor "long".  It should be "%td" I think. But the thing is, when you
> > fix a warning, you should damn well know what the hell you're doing, not
> > just shut it up.
> 
> Sorry, I made some falses assumptions about the printed type I guess...

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/