[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Ville-Pertti Keinonen <will@e...> |
| Subject: | Re: [Caml-list] Re: 64 bit windows |
On Thu, 2005-09-08 at 06:51 +1000, skaller wrote: > Actually MS decision is vastly more sensible than the gnu choice: It's not a GNU choice, it's what almost every vendor of 64-bit systems has used for more than a decade. It's nice to have a standard integer type for 64-bit values; C99 still isn't sufficiently established and C++ has no suitable standard types other than long. The Microsoft decision is only sensible in the context where Microsoft makes their decisions (only Windows matters, incompatibility with the rest of the world is good). > The real 'gotcha' is the Unix programmers that decided > it was OK to use 32 bit ints as addresses .. their code > will break under both models. It's also sometimes necessary to represent pointers as integers. I've seen more code that uses long for this purpose than int, often with assertions to ensure that sizeof(long) == sizeof(void *). All of my Unix C code works just by recompiling for amd64. On an LLP64 system, many things would break (garbage collectors and such where representing pointers as integers is necessary). Personally, I'm very happy that DEC, SGI, Sun, IBM, HP and Apple have all went with LP64.