On Fri, Feb 11, 2011 at 2:47 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 02/11/2011 06:05 AM, Rob Landley wrote: >>> >>> While this assumption works on QEMU's major hosts, it is not generally >>> true. >> >> It is generally true. There is exactly one operating system that >> decided to go its own way, and the insane legacy reasons they did so are >> explained here: >> >> http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx > > Unix could do that because it had the luxury of having introduced 64-bit > when they already were using int=long=32. So really nobody was using long > until 64-bit systems came along. Windows instead has to deal with the > legacy of 16-bit, when long was the only 32-bit type.
IIRC also Unix was in that situation once (short = int =16, long = 32 bits). > I have always agreed with you, but as much as I like LP64, I recently > changed my mind on this stance. stdint.h means that there is _no reason_ > why a program cannot be written portably so that it runs on both I32LP64 and > IL32LLP64 models. Using intptr_t is not different from using long. There's also the advantage that it is a bit more specific. > Someone has to do the work, of course, and it's surprising that two people > (Filip Navara and now Stefan) were brave enough to try it. :) It has to be > a well-audited change though, not a quick attempt at making it work. I'd still be interested to know if QEMU runs on win64. But even if it doesn't, changing longs to intptr_t and unsigned longs to uintptr_t is harmless enough that it should be applied nevertheless. Even if everybody stopped all win32/64 work after that, nothing would be lost except maybe some beauty in some beholder's eyes.
