Path: utzoo!utgpu!watserv1!watmath!att!att!pacbell.com!ucsd!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!math.lsa.umich.edu!math.lsa.umich.edu!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.atari.st
Subject: cross-compiling
Message-ID: <1990Oct29.235921.23294@math.lsa.umich.edu>
Date: 29 Oct 90 23:59:21 GMT
Sender: usenet@math.lsa.umich.edu
Reply-To: hyc@math.lsa.umich.edu (Howard Chu)
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 29
Uucp-Path: {mailrus,umix}!um-math!hyc

Just a little FYI: I discovered today (sigh) that the C compiler on
Sun Sparcstations always tries to align structure elements on longword
boundaries. Thus my "unix-compatible" (hah) TOS disassembler fails to
work, because there are extra pad bytes inserted to my structure declarations.
(e.g.,
	struct GEMHEADER {
		short GEM_MAGIC;
		long GEM_SEGS[GEM_NSEGS];
		long reserved;
		long unused;
		short GEM_FLAG;
	}
This defines the start of a TOS executable file. The structure, as defined,
is 28 bytes on an ST, and 32 bytes on a Sparc. Bleah.)

If you're trying to write portable code, don't assume you can read or write
structures in a single operation. If you're already using buffered I/O then
it's really not much more overhead to read X bytes at a time and fill structures
in explicitly, one element at a time...

Of course, if you're only writing for 680x0 architectures, this won't ever
be a problem (?) since data is aligned on word boundaries (2 bytes, 16 bits)
and not longword boundaries (4 bytes, 32 bits). [but watch out for those
single-byte declarations!  }-)  ]
--
  -- Howard Chu @ University of Michigan

Mac// - adv., q.v. MacToo, e.g.  McHave a McHappy McDay!
		McThanks, McYou MacToo!