Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: Failure of "long x(cp) char * cp; { return *((long *) cp); }" is a bug?
Message-ID: <2204@umcp-cs.UUCP>
Date: Sun, 29-Jun-86 10:15:15 EDT
Article-I.D.: umcp-cs.2204
Posted: Sun Jun 29 10:15:15 1986
Date-Received: Mon, 30-Jun-86 06:01:55 EDT
References: <6152@elsie.UUCP>
Reply-To: chris@maryland.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 36
Summary: no bug

In article <6152@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
>As I understand it, the code produced by some compilers from
>
>	long x(cp)
>	char * cp;
>	{
>		return *((long *) cp);
>	}
>
>will cause core dumps if the value of cp isn't "appropriately aligned".

>...  Doesn't the cast in the
>		return *((long *) cp);
>give the compiler all the evidence it needs that it should, *on its own*,
>produce code that's the equivalent of the function call?

[\S = section symbol]

No.  K&R, Appendix A, \S 14.4, p.~210:

  14.4  Explicit pointer conversions
  ...
    A pointer to one type may be converted to a pointer to another
  type.  The resulting pointer may cause addressing exceptions
  upon use if the subject pointer does not refer to an object
  suitably aligned in storage. ...

While you are verifying this, take a look at \S 16.  I think it is
amusing that as long ago as 1978, K&R identified most of the major
portability problems that many people are now seeing for the first
time.  (The big one they left out of \S 16 is null-pointer derefer-
encing.)  You were warned, eight years ago!  :-)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu