On Wed, Jan 23, 2008 at 12:33:47AM +0000, Daniel P. Berrange wrote: > 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 Another option is totry to fix things in the current API. Can we define a type which is an integer guaranteed to be of the expected type on the existing platforms (basically Linux/BSD/Solaris) and for which we can make sure the exact same size will be used on new platforms when added ? > ....simply replacing 'long' with 'long long' in these 5 APIs so we have > public APIs whose precision matches the wire encoding. This may be cleaner than adding 2 new data structures and 3 new entry points just for compatibility with 32 bits. If we actually duplicate, then as Rich suggested let's go for fixed size integer definitions like uint64 and the likes, to not get into more troubles later. Oh and mark the old structures and entry points as deprecated in the documentation, make sure the python/perl/java/etc. bindings use the new ones, and that all existing examples/virsh and docs are updated to the new ones. > 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. I don't think we would do this conciously in any C code but we should check the protocol and bindings generators (I think it is okay but better check again). Damn ... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list