Ordering of elts in structures

John Chambers jc at mit-athena.UUCP
Wed Apr 10 07:05:17 AEST 1985


> 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.)
 
But you've missed the major reason for the request for unaligned 
structures.  It's not to save space.  That is a peripheral concern.  
The reason is that sometimes you are handed a structure produced 
by someone else's program (on another machine or in another language 
or maybe just from a different release of the compiler) and you've 
gotta extract the data from it.  You don't always have the luxury 
of telling the sender what sort of data structures you can handle.  
He just might not listen to you.  More likely, he'll send the data 
however he damn well pleases (or however his compiler decided to 
pack it).  

What is needed is a way of saying "I know it's strange, but this 
is exactly what the data looks like" and having the compiler believe 
you.  This can be done in assembly language.  It can't be done in 
most "high-level" languages.  

One of the things that C sort of has going for it is that it is 
often possible to express things that would otherwise have to be 
in assembly language, thus decreasing the need for assembly language.  

Thus, the C bible says quite clearly (page 196) that "Within a structure, 
the object declared have addresses which increase as their declarations 
are read left-to-right".  Similarly, arrays must have their zero item
at the low address.   Now in a tru high-level language, this would be
silly.  But C isn't a high-level language.  It is a replacement for
assembly language.  Such specifications are very useful in a great
many applications.  

One place where the designers of C missed this was in alignment.  This
was a concession to high-level design ("The compiler should be free to
decide on representation") rather that low-level ("The programmer should
be able to specify the representation").  For those that need a high-level
language, this was a good decision.  For those that need precise control
of low-level details, it is a constant source of problems.

I, for one, would rather invite people to use a higher level language,
and leave C in its low-level state for those of us whose only alternative
is assembly language.  But then, that's probably because of the sort
of jobs I've been doing.  If I were doing AI work, I don't think I'd
much like C.

-- 

			John Chambers [...!decvax!mit-athena]

He who has made no mistakes has probably made nothing at all.



More information about the Comp.lang.c mailing list