Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site pur-phy.UUCP
Path: utzoo!linus!decvax!genrad!mit-eddie!mit-vax!eagle!mhuxt!mhuxi!mhuxa!houxm!ihnp4!ixn5c!inuxc!pur-ee!CSvax:Pucc-H:pur-phy!suitti
From: suitti@CSvax:Pucc-H:pur-phy.UUCP
Newsgroups: net.lang.c
Subject: Re: Orphaned Response - (nf)
Message-ID: <910@pur-phy.UUCP>
Date: Fri, 9-Sep-83 13:25:25 EDT
Article-I.D.: pur-phy.910
Posted: Fri Sep  9 13:25:25 1983
Date-Received: Sun, 11-Sep-83 04:43:35 EDT
References: <2764@uiucdcs.UUCP>
Organization: Purdue Univ. Physics Dept., W. Lafayette, IN
Lines: 87

My comment:
	You can eliminate the "cracks", within structures:
	If you assume that the order of items within a structure may be
	left to the compiler, then the compiler may sort the items into
	longest first.

The reply:
	What you have, then, is not C-as-we-know-it. "Within a structure, the
	objects declared have addresses which increase as their declarations
	are read left-to-right."  Removing that requirement would make life
	difficult for those of us who, for instance, read foreign (non-Unix)
	tapes directly into C structures, relying on the defined alignment
	of structures.

My answer:
	Unless I looked at both machines's compilers carefully,
and didn't really expect people to do this everywhere my programs
were likely to be ported, I would never require that info
sent/recieved would be in the structur's binary form.  For
instance, the binary byte order of a long is differant on a
pdp-11 than a Vax!  That blows that idea.  How much more so is
the whole structure likely to be differant?  A related note, I've
seen non-portable code of longs being played with using chars in
several programs:  The Gosling's EMACS info database routines
for one.
	I re-read chapter 6 (structures) of K & R.  There was no
explicit statement that structure members would be in any order.
When talking about the size of a structure it says: "But don't
assume that the size of a structure is the sum of the sizes of
it's members - because of alignment
requirements for different objects, there may be "holes" in a structure."
(chapter 6, page 130).  It doesn't say how big the holes would be, etc.
	I can only think of one program on my system that would stop working
if I hacked on the C compiler to sort by sizes (more on sorting later).
That's the kernel.  Structs are often used in device drivers to simplify the
syntax of getting at all the various registers that the device has.  There
are a couple of fixes for that too.

More comments:
	It would also make life more difficult when you
	decide to change a structure -- if you add a new object to an existing
	structure declaration you can simply read the old structure into
	the new one, set the value of the added object, and write it out
	again (you just specify different lengths on the read and write).

More reply:
	This can be risky at best, and of limited use.  If one has an
array in the middle of a structure, expanding it or contracting it is
going to upset things.  This is one of the most common structure mods
that I experience.  Under my compiler (the Ritche v7 compiler), adding
(or subracting) stuff at the end of the structure would be relatively
safe.  I prefer my programs to keep their data in ASCII while on disk,
at least, they should have that capability.  For one, it is easier to
debug a clear-text data file.  (I know, you never make mistooks).

More comment:
The whole scheme proposed also founders if objects within the structure
do not have power-of-two lengths. If your structure contains a char[3]
object, sorting it between length 4 and length 2 is not going to
eliminate the need for an alignment byte.

More reply:
I should have thought more about the sorting procedure.  The key
to sorting should be the ls (least significant) bits of each
"sizeof object".  Start with those elements that have (for
instance) their 3 ls bits zero.  Then follow those objects with 2
ls bits, then with one zero ls bit, then the odd sized ones.
Care should be taken that the sort is stable, that is, a structure
will be sorted the same every time, so that separate compilation
will still work.
	The UNIX kernel device driver's structures can be fixed
in three ways.  The first way is not to use structures for this
purpose.  The effort here would be unreasonable.  There are many,
many device drivers on many, many machines.  The second fix is
to have a command line switch to preserve order always.  That way
only the device drivers in the kernel need have "space - inefficient"
structures.  The third way is to leave structures alone that would
not have holes in them as defined.  This is probably safe.  Device
drivers use structures that have been carefully laid out.  I doubt if
there are any holes there anyway.
	I like the compile line switch, in general, for non-standard
features.  For instance, I wouldn't mind one for using single precision
floating point for single precision.  This can also be worked out.

Stephen Uitti (physics site manager)
...pur-ee!Physics:suitti
...purdue!Physics:suitti