Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: C machine
Message-ID: <9961@mimsy.UUCP>
Date: 27 Dec 87 05:10:44 GMT
References: <7535@alice.UUCP> <8226@steinmetz.steinmetz.UUCP> <461@auvax.UUCP> <163@bhjat.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 25

In article <163@bhjat.UUCP> bhj@bhjat.UUCP (Burt Janz) writes:
>I hold that a short is defined as ALWAYS being 16 bits, and a long as
>ALWAYS being 32 bits.  I don't know if I'm right in this regard,

Nope.  The dpANS says only that short >= 16 bits, int >= 16 bits, and
long >= 32 bits.

>but being stubborn, I always press the point of previous compiler/
>machine definitions.

Personally, I prefer the point of usefulness.

>So, on a 64-bit processor, what's an int?

I would say that, if the machine has a 64 bit address space and 64
bit arithmetic, but the `natural' arithmetic size is 32 bits, it
is 32 bits; otherwise it is 64.  I would make longs 64 (or perhaps
even 128) bits, and shorts quite possibly still 16 bits.  It would
be nice to have 8, 16, 32, and 64 bit values, and it seems natural
to make those `char', `short', `int', and `long' respectively.  This
might be a problem for program that assume either short==int or
long==int, though.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris