Xref: utzoo comp.lang.c++:13121 comp.lang.c:38800
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uwm.edu!ux1.cso.uiuc.edu!phil
From: phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <1991Apr29.050715.22968@ux1.cso.uiuc.edu>
Date: 29 Apr 91 05:07:15 GMT
References: <168@shasta.Stanford.EDU>
Organization: University of Illinois at Urbana
Lines: 38

shap@shasta.Stanford.EDU (shap) writes:

>2. If a trade-off has to be made between compliance and ease of
>porting, what's the better way to go?

User selectable.

>3. If conformance to the standard is important, then the obvious
>choices are

>	short	16 bits
>	int	32 bits
>	long	64 bits
>	void *	64 bits

That depends on the natural address size of the machine.  If the
machine uses 32 bit addresses, then (void *) should be 32 bits.
I would not want my address arrays taking up more memory than is
needed.

Is it really necessary that sizeof(void *) == sizeof(long)?

>How bad is it for sizeof(int) != sizeof(long). 

Would not bother me as long as sizeof(int) <= sizeof(long)

>4. Would it be better not to have a 32-bit data type and to make int
>be 64 bits?  If so, how would 32- and 64- bit programs interact?

Again it would depend on the machine.  If the machine has both 32 bit
and 64 bit operations, then do include them.  If a 32 bit operation
is unnatural to the machine, then don't.  If it has 16 bit operations
then that makes sense for short.
-- 
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/