🚀 go-pugleaf

In article <16360@cup.portal.com> Devin_E_Ben-Hur@cup.portal.com writes:
>Sorry, folks, this is from K&R I, p196, "8.5 Structure and union declarations
>... Within a structure, the objects declared have addresses which increase
>as their declarations are read left-to-right."

>There is similar language in the pANS and K&R II.  Reordering C structure
>members has never been and is not now correct behavior for a C compiler.

Let's ignore sorting ALL structure elements for a moment.  Let's consider a
compiler which simply puts each new structure element at the first offset
where that new element fits.  Many times such a compiler may have to put the
new element at the end (as per K&R and pANS).  Sometimes the compiler could
"take back" padding, that the compiler previously assumed was needed
(expressly forbidden by K&R and pANS).

Let's assume the compiler treats "sub-structures" as opaque black boxes and
doesn't try to stuff anything inside a sub-structure.  This will still allow
the compiler to implement structure assignment (e.g. to the sub-structures) as
simple memory copies.

This way programs that require certain structure elements at particular
offsets on a particular machine, could specify structure elements (e.g. pad1
pad2 ...) where padding would otherwise take place.

Under such a scheme, what otherwise portable programs would quit working?

Obviously, expressions like:

    &ptr->fieldx - &ptr->fieldy

may be (unexpectedly) negative.  I'm not sure that even with the needed casts,
that this sort of thing is portable.

Paul Scherf, Tektronix, Box 1000, MS 61-028, Wilsonville, OR, USA
paulsc@orca.WV.Tek.com     503-685-2734     tektronix!orca!paulsc