Just discovered that on x86_64, Windows and Linux differ in what they think sizeof(long) to be. http://lists.xensource.com/archives/html/xen-devel/2008-01/msg00736.html http://www.winehq.org/pipermail/wine-devel/2005-July/038602.html Windows i686: sizeof(long) == 4, sizeof(void*) == 4 Windows x86_64: sizeof(long) == 4, sizeof(void*) == 8 Linux i686: sizeof(long) == 4, sizeof(void*) == 4 Linux x86_64: sizeof(long) == 8, sizeof(void*) == 8 Unfortunately we have a number of APIs which use 'long' in the public header file for dealing with VM memory. Fortunately they are all using memory in size of KB, so we are not totally doomed until people start wanting to manage VMs with > 2 TB of RAM. Also fortunately, the wire-encoding for these APIs all uses hyper, so on the wire everything is 64-bit guarenteed. Eventually though we might want to consider adding struct virDomainInfo64 struct virNodeInfo64 virDomainGetMemory64 virDomainSetMemory64 virDomainSetMaxMemory64 ....simply replacing 'long' with 'long long' in these 5 APIs so we have public APIs whose precision matches the wire encoding. More immediately though, we need to be careful that there is no code that assumes sizeof(long) == sizeof(void*) - eg any places we cast pointers to integers and back again will break on Windows 64. Again fortunately, so far I can only find places going from int -> pointer -> int which is OK because we're not loosing precision. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|