Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!pyramid!batcomputer!braner
From: braner@batcomputer.UUCP
Newsgroups: comp.emacs,comp.sys.atari.st
Subject: Re: uEmacs38b Fixes for ATARI ST
Message-ID: <611@batcomputer.tn.cornell.edu>
Date: Sun, 5-Apr-87 11:31:28 EST
Article-I.D.: batcompu.611
Posted: Sun Apr  5 11:31:28 1987
Date-Received: Wed, 8-Apr-87 04:58:59 EST
References: <48200001@tub.UUCP> <273@xios.XIOS.UUCP>
Reply-To: braner@tcgould.tn.cornell.edu.UUCP (braner)
Organization: Theory Center, Cornell University, Ithaca NY
Lines: 22
Xref: utgpu comp.emacs:747 comp.sys.atari.st:2563
Summary: Beware of data type size assumptions

[]

(C experts hit 'j' now!)

It is a general problem with porting C programs that some C programmers
assume that a 'short' is 16 bits or that an 'int' is 32 bits or that a
pointer fits in a 'int'.  The latter at least produces a warning from
your compiler (or mine, anyway...), but the first two are real problems.

When porting to Megamax (16 bit ints, 8 bit shorts) I automatically convert
all shorts to ints and some ints to longs.  'Some' since most are OK, and
using longs will make the program large and slow.  You really have to
understand the program you're porting to know for sure where it's OK.

I would strongly recommend using the WORD, etc macros when _you_ write
C code to simplify porting later!  At least, use WORD when you access
OS data-structures that are 16-bits wide, and use LONG when you need
more than 16 bits.

- Moshe Braner

PS: Anybody got docs about writing GEM metafiles from a Megamax C program?