Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site calgary.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: net.lang.c
Subject: Re: Ordering of elts in structures
Message-ID: <340@calgary.UUCP>
Date: Mon, 1-Apr-85 16:17:28 EST
Article-I.D.: calgary.340
Posted: Mon Apr  1 16:17:28 1985
Date-Received: Fri, 5-Apr-85 02:07:55 EST
References: <479@lll-crg.ARPA>
Distribution: net
Organization: University of Calgary, Calgary, Alberta
Lines: 32

> In a previous news item concerning packet structures I stated that I
> had not seen any condition on the ordering of structure elements in
> the language definition with a caviat of not being sure.
> 
> Hunting this down in the back of K&R the language manual (page 192)
> it does state that structure elements have increasing addresses
> in order of declaration.

This sounds to me like a good candidate for deletion in the ANSI standard
for C. What's the point of specifying order if one doesn't specify alignment?
If the compiler re-orders the fields in decreasing order of alignment 
requirements it would never have to pad to align at all, even on machines 
requiring alignment.

This would seem to address the only legitimate reason for wanting a
"packed" attribute - desire to save space. (As has been pointed out by
others, the idea that you can transfer files between machines using
"packed" is naive.)

Of course, there's a problem with this. Sometimes one wishes to simulate
Simula-style prefixed classes in C, and this requires that one be able
to cheat on the typing in a way which would be screwed up if the compiler
re-arranged the fields. There are two possible solutions to this - add
structure prefixing to C, or add a facility to disable the field
re-arraingment. 

Either is another addition of course. Maybe it all just ought to be left
alone. Sigh...


     Radford Neal
     The University of Calgary