[python-win32] passing 'small' integers as 64 bit integers to COM functions

[Mark Hammond]

On 17/02/2009 6:17 PM, Shaer, Neta wrote:
> Hello,
>
> I’m using python 2.5 on windows (32 bit).
>
> I'm using some COM object from python.
> One of the functions in this COM objects expects VARIANT and operate
> according to the type of this VARIANT.
> The thing is that it does one thing if the VARIANT type is VT_UI4 (32
> bit integer) and a different thing for VARIANT of type VT_UI8 (64 bit
> integer).
> The python code that calls this function 'knows' what should be the type
> of the VARIANT. and in certain cases, the type of the VARIANT should be
> VT_UI8 (64 bit), though the actual value of the variable is small (i.e.
> can be contained in 32 bit). But in these cases python will
> automatically set the type of this variant to VT_UI4 and this will cause
> the COM function to do the wrong thing (and eventually fail).
> Is there any way to 'force' python to pass this VARIANT as VT_UI8 though
> its value is very small?

No - infact pywin32 doesn't support VT_UI8 at all - but it will use 
VT_I8 only when the value doesn't fit in 32 bits.  Note that MS 
documents *both* VT_I8 and VT_UI8 as being an invalid type in a variant:

from WTypes.h:

* VARENUM usage key,
  *
  * * [V] - may appear in a VARIANT
  * * [T] - may appear in a TYPEDESC
  * * [P] - may appear in an OLE property set
  * * [S] - may appear in a Safe Array
  ...

  *  VT_I1               [V][T][P][s]  signed char
  *  VT_UI1              [V][T][P][S]  unsigned char
  *  VT_UI2              [V][T][P][S]  unsigned short
  *  VT_UI4              [V][T][P][S]  unsigned long
  *  VT_I8                  [T][P]     signed 64-bit int
  *  VT_UI8                 [T][P]     unsigned 64-bit int

So it would appear our support for even VT_I8 is suspect.  To make 
matters less clear, we only support VT_I8 when *creating* a variant - we 
do not attempt to unpack VT_I8 or VT_UI8 from an incoming variant at all 
- in general we only support those explicitly declared by MS to be valid 
in variants (although there is almost no risk in accepting unsupported 
types on the way in that I can see)

BTW: it wouldn't be hard to argue that the COM object in question is 
insane - that the size of the integer passed shouldn't impact how it 
operates - but I guess it is what it is...

Cheers,

Mark