Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Unaligned Accesses (was Re: How to use silicon)
Message-ID: <25000@amdcad.AMD.COM>
Date: 27 Mar 89 23:04:48 GMT
References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP> <13@microsoft.UUCP> <362@bnr-fos.UUCP> <59@microsoft.UUCP> <343@unicads.UUCP>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 19
Summary:
Expires:
Sender:
Followup-To:

In article <343@unicads.UUCP> les@unicads.UUCP (Les Milash) writes:
| here's a question about "the large body of existing C code"...
| how many programmers assume that the address of a struct is the same
| as the address of its first member?  or that the members are arranged
| in address space in the same order they appear in the struct definition
| in the source code?  i wrote a program once that did that first evil,
| but now i realize that K&R never claims it'll work, and also there
| are legal ways around it that take no time or space.  it seems like
| as long as programmers don't do that kind of junk, then (having a
| compiler) sort the members of a struct by size is painless and free.

Unfortunately (?) it is not allowed.  Both K&R (section 8.5) and the
pANS (section 3.5.2.1) say that within a structure, the objects declared
have addresses that increase in the order in which they are declared.


	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)