64 bit architectures and C/C++

[Doug Gwyn]

In article <168 at shasta.Stanford.EDU> shap at shasta.Stanford.EDU (shap) writes:
>1. Do the C/C++ standards need to be extended to cover 64-bit
>environments, or are they adequate as-is?

This question presupposes something that is not true, namely that
64-bit environments differ from current environments.  In fact,
I've been using 64-bit C environments for years, in addition to
16-bit and 32-bit ones, with occasional dabbling in 60-bit environments.

The C standard does not presuppose any particular architecture.

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

There is no excuse for a new C implementation to not conform to the
C standard.

Note that the standard allows the C implementor much flexibility
when it comes to architecturally-determined choices.

>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

(You seem to have also assumed that a char is 8 bits.)
There is nothing particularly "obvious" about these choices;
I could readily imagine many other choices that would be both
standard conforming and useful.

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

There should not be any applications that depend on int and long
having the same size.

>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?

I don't know what you mean by a "32-bit program".

>Looking forward to a lively exchagne...

I don't see what there is to discuss.  The C standard specifies
minimum ranges for the basic types, and anything beyond that is
up to the implementor to decide, taking into account his customers'
needs.