Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rochester.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!mhuxr!ulysses!allegra!mit-eddie!genrad!teddy!panda!talcott!harvard!seismo!rochester!ken From: ken@rochester.UUCP (Ken Yap) Newsgroups: net.lang.c Subject: Re: the one and only objection to C Message-ID: <5062@rochester.UUCP> Date: Tue, 1-Jan-85 19:50:19 EST Article-I.D.: rocheste.5062 Posted: Tue Jan 1 19:50:19 1985 Date-Received: Thu, 3-Jan-85 03:48:48 EST References: <1265@orca.UUCP> <86@mit-athena.ARPA> <4841@utzoo.UUCP> <545@vu44.UUCP> Reply-To: ken@rochester.UUCP (Ken Yap) Organization: U. of Rochester, CS Dept. Lines: 30 Summary: ***** Asbestos suit on ***** There are two things which come to mind here: (1) I have seen an implementation of Pascal which allowed the programmer to specify the byte offset of each field. Thus the programmer gets complete control over the packing in the record/structure. (Even overlapping fields were possible. Ick!) The "packed" pragma would be the special case where the offsets are consecutive. (2) In most programs, it is irrelevant how the fields are arranged in the record and the programmer doesn't care. There could be another pragma that told the compiler to arrange the fields to minimize record size. This can be done by allocating storage to the largest fields first, ending with byte-sized (or even bit-sized) objects. Naturally this pragma should be turned off for compiling device drivers. Further to point (2), it seems that people who write device drivers are making assumptions about how their compiler aligns fields. Given that the drivers are not portable anyway, this is not an issue. There may be a case for making (2) the default behavior and making programmers use mechanism (1) for field alignment. A plus would be the extra information conveyed to driver modifiers. Ok, flame away. -- Ken Yap UUCP: (..!{allegra, decvax, seismo}!rochester!ken) ARPA: ken@rochester.arpa USnail: Dept. of Comp. Sci., U. of Rochester, NY 14627. Voice: Ken!