Signed word lengths and indexes

[dsimcha]

== Quote from bearophile (bearophileHUGS at lycos.com)'s article
> Walter Bright:
> > If we go back in the thread, the argument for the signed size_t argument was for
> > 64 bit address spaces.
> I was asking for signed word lengths and indexes on both 32 and 64 bit systems.
Sorry for not being more clear from the start.
> >With 32 bit address spaces, objects larger than 31 bits are needed.<
> I don't fully understand what you mean. On 32 bit systems I can accept arrays
and lists and collections (or a call to malloc) with only 2_147_483_648 items/bytes.
> On a 32 bit Windows with 3 GB RAM (and Windows itself set to use 3 GB) DMD
allows me to allocate only a part of those. In practice you can't allocate more
than 2 GB in a single block.
> On a 32 bit system I can desire arrays with something like 3_000_000_000 items
only when the array items are single bytes (ubyte, char, byte, bool), and such
situations are not so common (and probably 32bit Windows will not allow me to do it).
> (I am still writing a comment to another answer of yours, I am not so fast,
please be patient :-) )
> Bye,
> bearophile

That's because Win32 reserves the upper half of the address space for kernel
address space.  If you use the 3GB switch, then you get 3GB for your program and
1GB for the kernel, but only if the program is large address space aware.  If you
use Win64, you get 4 GB of address space for your 32-bit programs, but again only
if they're large address space aware.

Programs need to be explicitly be made large address space aware because some
legacy programs assumed it would never be possible to have more than 2GB of
address space, and thus used the most significant bit of pointers "creatively" or
used ints for things that size_t should be used for would break in unpredictable
ways if the program could suddenly see more than 2GB of address space.  You can
make a program large address space aware by using editbin
(http://msdn.microsoft.com/en-us/library/d25ddyfc%28v=VS.80%29.aspx).