I think that on some systems it is possible to tell the compiler to use
32-bit addresses and pointers while ints are 32-bits and longs are 64-bits.
This is the default ABI on many 64-bit machines unless it is overridden.

Also, there are only a few 64-bit architectures that can make use of true
64-bit addressing.  While the compiler may allow 64-scalar addressing in the
source code, somewhere in the build process, the address is usually munged
down to the size of the MMU quantum which can be 36-bit, 40-bit or 56-bit
depending on architecture.

CLN

-----------------------------------------------------

> -----Original Message-----
> From: Christian Biere [mailto:christianbiere@gmx.de]
> Sent: Monday, December 11, 2006 7:38 AM
> To: netbsd-users@NetBSD.org
> Subject: Re: amd64 stable for production ?
>
>
> Christian Biere wrote:
> > Consider the usual suspects like lists, hashtables and such. Since in C
> > these are typically pointer- not index-based they'll be twice as large
> > on a 64-bit architecture.
>
> P.S.: Structures suffer from this as well if people ignore alignment
> requirements and interleave int and pointers in the struct layout. For
> example in cases as this:
>
> struct blah {
> 	int foo;
> 	void *bar;
> 	int baz;
> };
>
> On a 32-bit machine this is typically 3*4 bytes large. On a
> 64-bit machine it
> grows to 2*4 + 8 + 4 (pad) bytes and potentially another 4 bytes trailing
> structure padding. If you rearrange it - something the compiler
> is not allowed
> to do - it can be decreased to 16 bytes.
>
> --
> Christian
>
>