[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Windows sizeof(long) != Linux sizeof(long)



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/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]