Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!eagle!hou5h!hou5a!hou5d!hogpc!houxm!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!uicsl!preece
From: preece@uicsl.UUCP
Newsgroups: net.lang.c
Subject: Re: Re: Orphaned Response - (nf)
Message-ID: <2802@uiucdcs.UUCP>
Date: Mon, 12-Sep-83 23:58:18 EDT
Article-I.D.: uiucdcs.2802
Posted: Mon Sep 12 23:58:18 1983
Date-Received: Tue, 13-Sep-83 18:53:09 EDT
Lines: 68

#R:pur-phy:-91000:uicsl:6400009:000:3436
uicsl!preece    Sep 12 08:56:00 1983

Further comments on altering the order of structure elements to
eliminate alignment padding.

				 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.
---
Yes, it's a pain to have to worry about things like the byte order
in longs. On the other hand, if the structure is long enough and
has enough individual elements, it may be faster to explicitly change
the byte order in the longs and use the rest of the structure. We
recently had to read tapes carrying twenty different bibliographic
databases, each in a different format, each consisting of records
averaging perhaps a thousand bytes making up about twenty strings,
forty longs, and various fixed location elements. The tapes ranged
from 100K up to 10M records. Knowing the layout of the record structures
we could manipulate only those parts that (1) we needed to use and (2) were
not in the expected byte order. Having to copy the structures one element
at a time would have been much slower, less clear, and would not have
helped at all with the byte-order problem (some of the data on some of the
tapes was in binary).
---
		I re-read chapter 6 (structures) of K & R.  There was no
	explicit statement that structure members would be in any order.
---
My quote is from page 196 (section 8.5 of the C Reference Manual,
Appendix A of K&R). "Within a structure, the objects declared have
addresses which increase as their definitions are read left-to-right."
Seems unequivocal.
---
	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).
---
I prefer to use ASCII files, too, when it's reasonable to do so. But
sometimes it's not reasonable to do so. If you're dealing with a lot of
numeric data it's not awfully efficient to be continually translating from
ASCII back into binary. And efficiency is still sometimes an issue --
both because (at our site, at least) the machine is not free and because
wall time is sometimes an issue. Ease of debugging is not the only thing
that has to be considered, nor does the use of stored structures make
debugging that much harder -- in our experience those structures are
sometimes EXAMINED during debugging, but are rarely CHANGED by hand during
debugging, so all you need is a simple filter to print out the contents
of the file, in most cases.
---
						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 could live with the command line option, though I'd make the current
way the default to preserve compatibility with all the existing Unix
programs in the world. The other idea is worse than the existing way,
since it means that structures could be one way or the other. This could
be painful in transporting software from one machine to another or in
debugging after changing a structure definition.
----------
scott preece
uiuc -- coordinated science lab
pur-ee!uiucdcs!uicsl!preece