Xref: utzoo comp.lang.c++:13222 comp.lang.c:38973
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <5535@goanna.cs.rmit.oz.au>
Date: 3 May 91 05:21:14 GMT
References: <168@shasta.Stanford.EDU> <4068@inews.intel.com> <1991May1.023356.8048@trl.oz.au>
Followup-To: comp.lang.c
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 55

In article <1991May1.023356.8048@trl.oz.au>, peter@llama.trl.OZ.AU (Peter Richardson - NSSS) writes:
> Hmmm. As I understand it. if you want to write truly portable code, you
> should never make assumptions about sizeof any integral types. We have
> a local header file on each machine type defining Byte, DoubleByte etc.
> For example, on sun4:
> 
> typedef unsigned char Byte;             // always a single byte
> typedef unsigned short DoubleByte;      // always two bytes
> typedef unsigned long QuadByte;         // always four bytes
> 
> If you want to use an int, use an int. If you want to use a 16 bit
> quantity, use a DoubleByte. To port to new machines, just change the
> header file. Purists may prefer "Octet" to "Byte".

Sorry.  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.

An anecdote which may be of value to people designing a C compiler for
64-bit machines:  there was a UK company who built their own micro-coded
machine, and wanted to put UNIX on it.  Their C compiler initially had
char=8, short=16, int=32, long=64 bits, sizeof (int) == sizeof (char*).
They changed their compiler in a hurry, so that long=32 bits; it was
less effort to do that than to fix all the BSD sources.  It also turned
out to have market value in that many of their customers had been just
as sloppy with VAX code.

sizeof (char) is fixed at 1.  However, it should be quite easy to set up
a compiler so that the user can specify (whether in an environment variable
or in the command line) what sizes to use for short, int, long, and (if you
want to imitate GCC) long long.  Something like
	setenv CINTSIZES="16,32,32,64"	# short,int,long,long long.
The system header files would have to use the default types (call them
__int, __short, and so on) so that only one set of system libraries would
be needed, and this means that using CINTSIZES to set the sizes to something
other than the defaults would make the compiler non-conforming.
Make the defaults the best you can, but if you let people over-ride the
defaults then the task of porting sloppy code will be eased.  Other vendors
have found the hard way that customers have sloppy code.

-- 
Bad things happen periodically, and they're going to happen to somebody.
Why not you?					-- John Allen Paulos.