[Libvir] Windows sizeof(long) != Linux sizeof(long)
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 -=|
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
Oh yes. I haven't even tried Windows x86-64 (only 32 bit Windows). I don't think there is even a version of MinGW which is available for it. Another problem is going to be for all the places that we assume long == sizeof pointer (eg. all the XDR code, written originally for Sun OS 4 on SparcStations). At least gcc warns about this one. Portable XDR library coming up soon.
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
This has come up before. _Please_ can we use the definitions in stdint.h! We want integers of a specific size, so let's use integers of a specific size, not just guess about what the size might be. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Quoting "Richard W.M. Jones" <rjones@redhat.com>:
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
Oh yes. I haven't even tried Windows x86-64 (only 32 bit Windows). I don't think there is even a version of MinGW which is available for it.
Actually, there is. Unofficial and still experimental but it might be useful for testing and finding bugs: http://sourceforge.net/projects/mingw-w64/ http://www.drangon.org/mingw/ -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
On Wed, Jan 23, 2008 at 08:39:46AM +0000, Richard W.M. Jones wrote:
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
This has come up before. _Please_ can we use the definitions in stdint.h! We want integers of a specific size, so let's use integers of a specific size, not just guess about what the size might be.
Seconded (I didn't understand the objections last time this came up). regards john
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Pau Garcia i Quiles -
Richard W.M. Jones