Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!amd!eager
From: eager@amd.UUCP
Newsgroups: comp.arch
Subject: Re: Available no. of registers
Message-ID: <3510@amd.UUCP>
Date: Tue, 27-Jan-87 04:47:46 EST
Article-I.D.: amd.3510
Posted: Tue Jan 27 04:47:46 1987
Date-Received: Wed, 28-Jan-87 06:35:50 EST
References: <3810002@nucsrl.UUCP> <926@mips.UUCP> <759@vaxb.calgary.UUCP> <213@ames.UUCP>
Organization: AMD Applications, Santa Clara, CA
Lines: 31
Summary: No more random pointer conversions!!

In article <213@ames.UUCP>, fouts@orville (Marty Fouts) writes:
> 
> The magic in C is that any kind of pointer can be assigned the address of
> any kind of data, provided that the data has an address (lvalue in K&R)
> via the classic cast:
> 
> Some_kind X;
> Other_kind *Y ;
> 
> Y = (Other_kind *) &X;
> 
> 
> This is used heavily in C.  The semantics of many Un*x kernels and more than
> a few applications programs would break without it.  The problem occurs when
> you do pointer arithmetic on Y.  It is perfectly legitimate to write:
> 
> X = *(Some_kind *) (Y+1);
> 
> and get at whatever is one Sizeof(Other_kind) beyon the original X in
> memory.
> 
> Of course, if pointers have the same "shape," it becomes possible to leave
> out the type casts, making the code difficult to port.

Oh, what a mess!!  One of the parts of C which is cleaned up in the ANSI
draft standard is the use of casts to convert pointer values.  
In a conforming compiler, none of the above is true.  
The only conversions that may be performed on pointers is
to convert them to (void *) and back to the SAME type.  On some machines,
the conversion to (char *) and back is possible, but this is implementation
defined behavior, and not portable.