[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0901151300150.26467@quilx.com>
Date: Thu, 15 Jan 2009 13:19:13 -0600 (CST)
From: Christoph Lameter <cl@...ux-foundation.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Rusty Russell <rusty@...tcorp.com.au>, Ingo Molnar <mingo@...e.hu>,
akpm@...ux-foundation.org, andi@...stfloor.org, ak@...ux.intel.com,
rth@...ddle.net, sfr@...b.auug.org.au, travis@....com,
linux-kernel@...r.kernel.org
Subject: Re: [patch 2/8] compiler-gcc.h: add more comments to RELOC_HIDE
On Wed, 14 Jan 2009, Linus Torvalds wrote:
> > > The cast should cause the C compiler to drop all assumptions about size.
> >
> > No, and that's the point. Sorry, at this point you need to talk to a gcc expert. As I have said, I did and I believe what he told me.
>
> Yeah, I personally believe in the "should cause the C compiler" part, but
> gcc doesn't work that way. It will remember where the value came from,
> even when the pointer has been cast to something else.
If so then the compiler is crap. Casting a pointer to long needs to
get a scalar without assumptions about the size of the structure that the
pointer was going to remaining a factor.
All of this originated in some discussion in the 2.5.X days. Could we make
sure that this is indeed the case?I have never seen any ill effect from
the casts to long nor do the failure scenarios given here make too much
sense (like adding a pointer to the address of a constant string passed as
the source argument to strcpy????).
>From the include/compiler*.h files it looks as if we are supporting 3
classes of compilers. Of those only gcc has this sickness.
--
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/
Powered by blists - more mailing lists