Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!rutgers!labrea!aurora!ames!sdcsvax!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga
Subject: short, long, int and standards (was: Manx C)
Message-ID: <4662@jade.BERKELEY.EDU>
Date: Mon, 10-Aug-87 04:38:04 EDT
Article-I.D.: jade.4662
Posted: Mon Aug 10 04:38:04 1987
Date-Received: Tue, 11-Aug-87 01:57:33 EDT
References: <4540@jade.BERKELEY.EDU> <1836@vax135.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Distribution: comp
Organization: Missionaria Phonibalonica
Lines: 57
Keywords: look at the assembly.

In article <1490@crash.CTS.COM> adamsd@crash.CTS.COM (Adams Douglas) writes:
<I do not have a single instance of 'int' as a type token anywhere in
<my code. Everything is explicitly 'long' or 'short'.

Each of the three types has (well, should have) a place.

Any variable that may be greater 32K (64K unsigned) should be a long.
Shorts and ints may not be big enough to hold them.

Any variable that is less than 32K (64K unsigned) and needs to be
small (you've got an array full of them, for instance) should be a
short.

Any variable that is less than 32K (64K unsigned) for which size
doesn't matter should be an int. Int's are the "natural" size of the
machine. This is sometimes interpreted to mean "fastest," but that is
never explicitly stated (I wish it were, so I could pound Lattice over
the head to deliver a compiler with 16 bit ints).

The Amiga has a split personality. The 68K has 16 bit ints as the
"natural" size. But DOS & the Exec are full of functions that expect
32 bit ints on the stack, so it can be argued that 32 bits is the
natural size for an int. Since I habitually write "int" to get the
fastest thing I can, compilers that use the 32 bit model are annoying.

Note that chars can be used for arithmetic, but probably shouldn't. If
you do that, *please* declare things as either "signed char" or
"unsigned char". Char doesn't default to either signed or unsigned, so
not specifying it can create headaches for people porting your code to
a larger machine later. (Like, for instance, porting it from an 11 to
a VAX).

Now, for a note on standards:

As a student of languages and software development tools, I think
standards disgusting. They freeze the state of the art, and make
people drop more interesting lines of work to conform to them.

As a software developer, I *like* standards. They mean I can write
code on one machine, and have a reasonable chance of it working on a
second machine. BUT ONLY IF COMPILERS FOLLOW THEM.

For this reason, pointing out places where some compiler differs from
a standard is important. If the difference is something that language
implementers could easily fall into, it needs to be referred to the
correct group. If that group has beaten it to death, and there is an
agreed-upon interpretation, then it should be referred to the group
appropriate for that implementation of the language. In those groups,
pointing out that this *is* a bug (and saying why it's a bug if people
disagree) and a workaround, is entirely appropriate.

	<mike
--
But I'll survive, no you won't catch me,		Mike Meyer
I'll resist the urge that is tempting me,		ucbvax!mwm
I'll avert my eyes, keep you off my knee,		mwm@berkeley.edu
But it feels so good when you talk to me.		mwm@ucbjade.BITNET