Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!teddy!panda!talcott!harvard!seismo!brl-tgr!tgr!cottrell@nbs-vms.ARPA From: cottrell@nbs-vms.ARPA Newsgroups: net.lang.c Subject: alignment of struxures/portability Message-ID: <7075@brl-tgr.ARPA> Date: Mon, 7-Jan-85 17:07:56 EST Article-I.D.: brl-tgr.7075 Posted: Mon Jan 7 17:07:56 1985 Date-Received: Wed, 9-Jan-85 02:46:03 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 15 /* 1) alignment i realize that allowing unaligned struxures may bomb on some machines. my point is: make the programmer add the alignment bytes explicitly if this is so. i know, more work. but this then allows the programmer to take advantage of nonalignment where permissible. i know, non-portable. okay, then allow nonaligned struxures and let the compiler generate shifting/masking code to realign the long int. i know, inefficient. to robert elz: does your compiler *really* align everything (even character data) on longword boundaries? what machine/system? 2) portability as you have guessed by now, things are neither absolutely portable nor absolutely nonportable. it is a spectrum. its either *kinda portable* or *mostly portable* or *barely portable*. welcome to reality. */