Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))

[Blue Swirl <blauwirbel@gmail.com>]

On Fri, Feb 11, 2011 at 2:47 PM, Paolo Bonzini <pbonzini@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.