Subject: Re: C Language Standard(s)
To: None <current-users@NetBSD.ORG>
From: Mike Long <mike.long@analog.com>
List: current-users
Date: 12/22/1995 11:47:41
>Date: Fri, 22 Dec 1995 07:50:06 -0500
>From: "John F. Woods" <jfw@jfwhome.funhouse.com>

>There is also no guarantee in the Standard that "long" is the longest
>integral type, though any longer types ought to at least conform to the
>Standard in reasonable ways ("long long" is a syntax error, damnit!),

"long long" is part of gcc, and we're stuck with it.

>There is an implicit promise, courtesy of the mystical "spirit of C", that
>"long" is at least an efficient data type, though not the fastest natural
>data type of a machine.  It is thus unnatural for "long" to be 64 bits on
>a 32-bit machine.

Not really.  "long" is guaranteed to be at least 32 bits, which is
inefficient on 16-bit machines (remember those?).  Even so, I agree
that we shouldn't make "long" a 64-bit type on 32-bit machines.

Code should use quad_t (int64_t?) if it needs a 64-bit integer.
-- 
Mike Long <mike.long@analog.com>           http://www.shore.net/~mikel
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil