Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!ut-sally!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: Failure of "long x(cp) char * cp; { return *((long *) cp); }" is a bug?
Message-ID: <4614@sun.uucp>
Date: Sun, 29-Jun-86 16:53:30 EDT
Article-I.D.: sun.4614
Posted: Sun Jun 29 16:53:30 1986
Date-Received: Tue, 1-Jul-86 02:01:52 EDT
References: <6152@elsie.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 38

> Isn't this really a compiler bug?  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?

A piece of software has a "bug" if it's supposed to do something and it
doesn't; for instance, if it's supposed to generate correct code and it
generates incorrect code instead.  The C compiler isn't *supposed* to do
unaligned copying in circumstances like this, so it can hardly be a "bug" if
it doesn't.

> Does the latest version of X3J11 have anything to say on the matter?

The August 11, 1985 draft says:

	C.3.3.2 Address and indirection operators

	...

	Semantics

	...

	     If an invalid value has been assigned to the pointer, the
	behavior of the unary * operator is undefined.  Such invalid
	values include ... *an address inappropriately aligned for the
	type of the object pointed to*...

I *very* sincerely doubt this has been changed in any later drafts.  Such
dereferences are uncommon occurrences, and a programmer can damn well write
their own code to do the unaligned copy.

So a C compiler which doesn't generate unaligned copies is perfectly within
its rights to do so, and has no bug.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)