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