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 -=|