Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!elroy!cit-vax!tybalt.caltech.edu!yair
From: yair@tybalt.caltech.edu (Yair Zadik)
Newsgroups: comp.lang.c
Subject: Re: foo = *((bar *)stuff)
Message-ID: <10535@cit-vax.Caltech.Edu>
Date: 29 Apr 89 08:37:29 GMT
References: <712@tekno.chalmers.se>
Sender: news@cit-vax.Caltech.Edu
Reply-To: yair@tybalt.caltech.edu.UUCP (Yair Zadik)
Organization: California Institute of Technology
Lines: 26

In article <712@tekno.chalmers.se> d83_sven_a@tekno.chalmers.se (Sven (Sciz) Axelsson) writes:
>Am I really out of line, or is this a true-to-God bug in the final release
>of MPW C 3.0?? Isn't this code supposed to assign the integer value contained
>at memory position 10 to the variable x?
>
>	x = *((int *)10);
>
>In MPW C 3.0 this generates exactly the same code as would x = 10.
>Am I right or am I right?
>
>	Sven Axelsson		d83_sven_a@tekno.chalmers.se

Sounds like a bug to me.  Correct me if I'm wrong, but (int *) 10 should
convert the integer 10 to a pointer, then the * should dereference the
pointer, which on most (*not* all) machines should read location 10 of
memory.  Note that this is extremely nonportable and very machine (even
compiler) dependent.  How an integer is translated into a pointer is not
defined (unless the integer is 0 which is translated to a null pointer) and
may vary depending on the compiler, although it usually (again *not* always)
stays the same on a single machine if there is a single obvious translation.
On 80x86 machines this can cause problems since 'far' pointers may be 
different from 'near' pointers, and pointers can be dependent on segment
registers. USE WITH CAUTION.

yair@tybalt.caltech.edu
yair@romeo.caltech.edu