Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven.umd.edu!ncifcrf!lhc!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <16070@smoke.brl.mil>
Date: 6 May 91 20:49:45 GMT
References: <1991May1.023356.8048@trl.oz.au> <5535@goanna.cs.rmit.oz.au> <TMB.91May3225038@volterra.ai.mit.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 15

In article <TMB.91May3225038@volterra.ai.mit.edu> tmb@ai.mit.edu (Thomas M. Breuel) writes:
>In essence, this is actually what the C standard does, if one
>continues to use the current data types with roughly their current
>meaning: "short" is close to, and at least 16 bits, and "long" is
>close to, and at least 32 bit. The emphasis here is on "close to", and
>this should probably be made explicit in the standard, since
>programmers pragmatically do, and need to, rely on it to be able to
>estimate what the space requirements of their programs will be.

It was not the intention of the C standard to require the "close to"
attribute as you describe it.  Some architectures are such as to make
that an impractical implementation, and on such architectures a char
might even be 128 bits.  (However, most implementations will make an
exception for "char" and pack them fairly tightly into a word, even
though it does slow down operations on char type considerably.)