Re: Memory ownership, parameters, variants, etc.

John Carlyle-Clarke <john.cc@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> What about the above question (about passing Variants by value) when
> dealing with automation type library marshalling? For it to work
> across process or machine boundaries I suppose it would *have* to be
> copied

Yes, it would be copied in this case, but it happens transparently. A
VARIANT you pass in, and any data it refers to, is serialized
("marshalled") into a memory buffer and transferred over to the callee.
There it is unmarshalled and an exact copy of the data is built and
passed to the callee. After this call returns, the copy is destroyed.
[out] and [in, out] parameters travel back in the same way.

> but what about when passing to an automation DLL?

In a direct call with no marshalling involved, there is no intervention
between the caller and the callee. COM runtime is out of the picture. So
the call is done with the usual C-style parameter passing. No data is
copied unless the code on either side of the call does it explicitly.

> Also, can you explain the latter part of this (from
> http://www.mvps.org/vcfaq/com/4.htm )
>
> "Note that the VARIANT doesn't own the storage for the embedded
> struct, but VariantClear will free the content of the struct by
> calling IRecordInfo::RecordClear. [...] note that the mechanism for
> storing struct data in a VARIANT is not fully documented. For example
> it isn't clear how a struct can be returned in an [out] VARIANT
> argument without producing memory leaks."

When UDTs were added to Automation, the spec never said how the memory
for the struct itself should be allocated. VariantClear (with the help
of IRecordInfo::RecordClear) destroys the fields of the structure (e.g.
if the structure has a BSTR or a SAFEARRAY* field, they would be freed
with SysFreeString and SafeArrayDestroy correspondingly) but does not
free the memory possibly allocated for the structure itself (for all it
knows, the struct might be a local variable on the stack). Since there
is no convention on how to allocate and free this memory uniformly, any
parameter passing scheme which involves different parties allocating and
freeing memory becomes impossible. This leaves only pure [in]
parameters, where the caller both allocates and deallocates.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • Re: compilation of ms crypto api program
    ... >> one variant and to access it via the other variant. ... > allocate memory of the size of the base type. ... only the memory for that specific variant is allocated. ... > about is who is able to read the program's memory and swap file while ...
    (sci.crypt)
  • Re: [PATCH 10 of 20] ipath - support for userspace apps using core driver
    ... The memory that we allocate with dma_alloc_coherent is indeed being ... char device's release method is called. ... so I conclude that the struct pages are leaking. ...
    (Linux-Kernel)
  • [1/2] [NET] link_watch: Move link watch list into net_device
    ... My memory is failing me:) ... makes sense to allocate some memory for it in net_device rather ... somewhat magnified) without singleevent but it's now plugged ... static unsigned char default_operstate(const struct net_device *dev) ...
    (Linux-Kernel)
  • [PATCH 2/6] memcg: allocate page_cgroup at boot (hunk fix)
    ... Allocate all page_cgroup at boot and remove page_cgroup poitner ... from struct page. ... Remove page_cgroup pointer reduces the amount of memory by ...
    (Linux-Kernel)
  • Re: structs
    ... >> and i want to allocate it memory, should i allocate enough to hold the ... > For an instance of the struct, ... > of memory to hold both the struct instance and the stuff ...
    (comp.lang.c)
Loading