brooks@lll-crg.ARPA (Eugene D. Brooks III) (03/28/85)
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.
radford@calgary.UUCP (Radford Neal) (04/02/85)
> 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
jc@mit-athena.UUCP (John Chambers) (04/09/85)
> 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.