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.
*/