Checksum: 62019
Lines: 19
Path: utzoo!sq!msb
From: msb@sq.uucp (Mark Brader)
Date: Mon, 28-Dec-87 16:34:03 EST
Message-ID: <1987Dec28.163403.24137@sq.uucp>
Newsgroups: comp.lang.c
Subject: Re: C machine
References: <7535@alice.UUCP> <8226@steinmetz.steinmetz.UUCP> <461@auvax.UUCP> <163@bhjat.UUCP> <9961@mimsy.UUCP>
Reply-To: msb@sq.UUCP (Mark Brader)
Organization: SoftQuad Inc., Toronto

On the topic of of short/int/long, Chris Torek (chris@mimsy.UUCP) writes:
> Nope.  The dpANS says only that short >= 16 bits, int >= 16 bits, and
> long >= 32 bits.

This is misleading in the context; the dpANS *also* says that short <= int
and int <= long.  So the method adopted by a 64-bit machine in the past,
where long = 32 bits "because that's what everybody assumes", and
int = 64 bits "because that's the natural size", would be non-conforming.

On a 64-bit machine, I would think that int = 32 bits, long = 64 bits,
would be natural.  However, if I found that I was dealing with a lot
of code that thought long = 32 bits or if needlessly "long" arrays were
chewing up my memory, I would consider having int = 32 bits, long = 32 bits,
"long long" = 64 bits.  "long long" is allowed by the dpANS as a "common
extension".  It renders the program non-portable but any program that
needs more than 32 bits in an integer is non-portable in any case.

Mark Brader		"VAX 3 in 1 carpet care -- now 129.95 pounds"
utzoo!sq!msb, msb@sq.com