Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mit-athena.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!mit-athena!jc From: jc@mit-athena.UUCP (John Chambers) Newsgroups: net.lang.c Subject: Re: Ordering of elts in structures Message-ID: <163@mit-athena.UUCP> Date: Tue, 9-Apr-85 16:05:17 EST Article-I.D.: mit-athe.163 Posted: Tue Apr 9 16:05:17 1985 Date-Received: Fri, 12-Apr-85 00:00:23 EST References: <340@calgary.UUCP> Organization: MIT Project Athena Lines: 51 > 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.