32 bit integer size on 64 bit processor and OS

Question

Although not strictly a dbx question, I think the audience here is the correct one to bounce this off of:
I'm curious: Why are 64 bit processes compiled with the -xarch=v9 switch having a 32 bit integer size, versus having 64 bit integer size?
Although not cast in stone, and implementation dependent, an "int was originally intended to be the "natural" word size of the processor - to use the processor's "natural" word size to improve efficiency (avoid masking, etc).".
I know you 'force' more 64 bit use (see some of Sun's doc on this below).
===============
The 64-bit Solaris operating environment is a complete 32-bit and 64-bit application and development environment supported by a 64-bit operating system. The 64-bit Solaris operating environment overcomes the limitations of the 32-bit system by supporting a 64-bit virtual address space as well as removing other existing 32-bit system limitations.
For C, C++, and Fortran software developers, this means the following when compiling with -xarch=v9,v9a, or v9b in a Solaris 7 or Solaris 8 environment:
Full 64-bit integer arithmetic for 64-bit applications. Though 64-bit arithmetic has been available in all Solaris 2 releases, the 64-bit implementation now uses full 64-bit machine registers for integer operations and parameter passing.
A 64-bit virtual address space allows programs to access very large blocks of memory.
For C and C++, the data model is "LP64" for 64-bit applications: long and pointer data types are 64-bits and the programmer needs to be aware that this change may be the cause of many 32-bit to 64-bit conversion issues. The details are in the Solaris 64-bit Developer's Guide, available on AnswerBook2. Also, the lint -errchk=longptr64 option can be used to check a C program's portability to an LP64 environment. Lint will check for assignments of pointer expressions and long integer expressions to plain (32-bit) integers, even for explicit casts.
The Fortran programmer needs to be aware that POINTER variables in a 64-bit environment are INTEGER*8. Also, certain library routines and intrinsics will require INTEGER*8 arguments and/or return INTEGER*8 values when programs are compiled with -xarch=v9,v9a, or v9b that would otherwise require INTEGER*4.
Be aware however that even though a program is compiled to run in a 64-bit environment, default data sizes for INTEGER, REAL, COMPLEX, and DOUBLE PRECISION do not change. That is, even though a program is compiled with -xarch=v9, default INTEGER and REAL are still INTEGER*4 and REAL*4, and so on. To use the full features of the 64-bit environment, some explicit typing of variables as INTEGER*8 and REAL*8 may be required. (See also the -xtypemap option.) Also, some 64-bit specific library routines (such as qsort(3F) and malloc64(3F)) may have to be used. For details, see the FORTRAN 77 or Fortran 95 READMEs (also viewable with the f77 or f95 compiler option: -xhelp=readme).
A: No program is available that specifically invokes 64-bit capabilities. In order to take advantage of the 64-bit capabilities of your system running the 64-bit version of the operating environment, you need to rebuild your applications using the -xarch=v9 option of the compiler or assembler.

Answer 1

I think that this was basically to keep down the headaches in porting code (and having code that will compile to both 32bit and 64bit object files). int is probably the most common type, so by keeping it at 32bits, the LP64 model has less effect on code that was originally written for 32bit platforms.
If you want to have portable code (in terms of the sizes of integral types), then you should consider using int32_t, int64_t etc from inttypes.h. Note that this header is post-ANSI C 90, so might not be portable to old C/C++ compilers.
A+
Paul