Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!snorkelwacker.mit.edu!ai-lab!life!tmb From: tmb@ai.mit.edu (Thomas M. Breuel) Newsgroups: comp.lang.c Subject: Re: 64 bit architectures and C/C++ Message-ID: Date: 4 May 91 02:50:38 GMT References: <168@shasta.Stanford.EDU> <4068@inews.intel.com> <1991May1.023356.8048@trl.oz.au> <5535@goanna.cs.rmit.oz.au> Sender: news@ai.mit.edu Followup-To: comp.lang.c Organization: MIT Artificial Intelligence Lab Lines: 39 In-reply-to: ok@goanna.cs.rmit.oz.au's message of 3 May 91 05:21:14 GMT You have just made a non-portable assumption, namely that there *is* an integral type which holds an octet and that there *is* an integral type which holds two octets, and so on. If you want "at least 8 bits", then use {,{,un}signed} char, and if you want "at least 16 bits", then use {,unsigned} short. The ANSI standard guarantees those. There is no need to introduce your own private names for them. If you want "exactly 8 bits" or "exactly 16 bits", you have no reason to expect that such types will exist. I am greatly disappointed that C++, having added so much to C, has not added something like int(Low,High) to the language, which would stand for the "most efficient" available integral type in which both Low and High were representable. The ANSI C committee were right not to add such a construct to C, because their charter was to standardise, not innovate. I think allowing the programmer to specify arbitrary precision integers is equally bad, since it adds too much complexity to the language and to compilers. A good compromise would be to provide a set of precisions that can be supported on current machines and extend the language standard as newer, more powerful machines become available. 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. When machines capable of handling larger integer data types become available, new names for the new data types should be introduced. Perhaps a more consistent naming scheme would be good: int8 (>= 8bit integer), ..., int128 (>= 128 bit integer), etc. Thomas.