Possible bug with DECIMAL type in VARIANT

[hcldan]

Summary

I've been looking around at supporting VARIANT.

I had a bit of trouble but found a good way to deal with BSTR. It contains a pointer in mem and therefore the VARIANT_0_0_0 member for it is a ManuallyDrop

Anonymous: VARIANT_0_0_0 {
  bstrVal: ManuallyDrop::new(
    // When made this way, the BSTR will have memory created in windows
    // so we don't have to maintain a ref to the original data.
    match BSTR::from_wide(&value) {
      Ok(b) => b,
      Err(err) => return Err(err),
    }
  ),
},

You can see that in the drop for BSTR the memory is deallocated from windows.

I started looking at DECIMAL support in VARIANT_0_0_0 and it looks like it takes a pointer to a DECIMAL

I would have expected it to take some kind of ManuallyDrop<DECIMAL_WRAPPER> that surrounds a pointer to the innards.
If I get a VARIANT of this type as a result of a COM call, do I need to worry about the pointer to the DECIMAL? Who owns that memory? How does it get cleaned up?

Crate manifest

No response

Crate code

No response

[kennykerr]

Did you try windows 0.53? It has improved VARIANT support.

https://github.com/microsoft/windows-rs/releases/tag/0.53.0

#2786
#2788

BSTR is directly supported and we could add support for DECIMAL if desired.

[hcldan]

Oh my... 0.53 is a really hefty change to what we've been using.
I'll have to look into this. Are there notes on migrating?

I can't seem to figure out how to get my IDispatch out of the VARIANT now...

[hcldan]

Well... @kennykerr, I already had support for converting all of the various VT_* types.
The 0.53.0 update, or anything beyond, will be impossible for me to start using until you deliver support for all remaining types.

[kennykerr]

Let's keep the conversation in one place. Closing as duplicate of #2877.