Re: 128 bit integers
- From: Chris Croughton <chris@xxxxxxxxxxxx>
- Date: Thu, 28 Jul 2005 16:31:10 +0100
On Thu, 28 Jul 2005 15:10:11 +0200, jacob navia
<jacob@xxxxxxxxxxxxxxxx> wrote:
> 4) What other implications can this new type have? I would have
> loved to use long long for this, long for 64 bit, int for 32
> bits, etc. But this is not possible for compatibility reasons.
> There is too much software there that assumes long long is 64 bits,
> not 128.
Any software which assumes any specific size of a type is broken.
Certainly with long long, which hasn't been around for very long
(apologies for the pun) so hasn't got the excuse of "there were only 16
bit machines around when we wrote it". long long is /at least/ 64 bits,
it could easily be 72 on a 24 bit machine for instance.
Probably just adding the new type to stdint.h and inttypes.h with
appropriate macros would be adequate. An implementation can happily
define types of form intN_t and uintN_t (and the least and fast
variations) and the PRIdN (etc.) macros without encroaching on the user
namespace in those headers.
Since, however, the macros and types should not be defined if the
headers are not included, the underlying type should be in the
implementation namespace, starting with underscore (so _int128_t and
_uint128_t would be reasonable) unless you can easily detect which
header is included and switch the keywords off. long long long is silly
in my view (as is long long).
Chris C
.
- Follow-Ups:
- Re: 128 bit integers
- From: jacob navia
- Re: 128 bit integers
- References:
- 128 bit integers
- From: jacob navia
- 128 bit integers
- Prev by Date: Re: gcc4 and lvalues
- Next by Date: Re: 128 bit integers
- Previous by thread: Re: 128 bit integers
- Next by thread: Re: 128 bit integers
- Index(es):
Relevant Pages
|
