Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!calgary!ctycal!ingoldsb
From: ingoldsb@ctycal.UUCP (Terry Ingoldsby)
Newsgroups: comp.arch
Subject: Structures' member order in C
Keywords: I fall on my sword.
Message-ID: <336@ctycal.UUCP>
Date: 20 Feb 90 21:37:21 GMT
Organization: The City of Calgary, Ab
Lines: 33

Many people have (deservedly) roasted me for misquoting K&R (this
verges on sacrilege :^).  I originally said that K&R explicitly
states that members may be reordered by the compiler.  What K&R
*really* said was:

	Within a structure, the objects declared have addresses which
	increase as their declarations are read left-to-right.  Each
	non-field member of a structure begins on an addressing boundary
	appropriate to its type;...
          (K&R First edition, Appendix A section 8.5 page 196)

Nonetheless my point is valid that K&R *does* say that members can be
padded so as to align appropriately.  Note that some C compilers may
violate this `addresses which increase as their declarations are read'
part of the definition.  I have no examples of this but suspect some
people might consider it a feature.

I originally got myself into this mess by misreading something in the
VMS VAXC manual (pg 6-20 VAXC 2.3 Guide to C) that *seemed* to state
that `Other C implementations may align members differently' referring
to the issue of padding.  I read it to mean that they might change
the order.

I stand by the other points I made regarding the need for padding
in a RISC architecture.




-- 
  Terry Ingoldsby                ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                 or
  The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb