[Bug 14078] New: Rewrite typelib marshaller on top of NDR functions

http://bugs.winehq.org/show_bug.cgi?id=14078

Summary: Rewrite typelib marshaller on top of NDR functions
           Product: Wine
           Version: CVS/GIT
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ole
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

[Copied from wine-devel.]
Dan K. wrote in 
http://www.winehq.org/pipermail/wine-devel/2008-June/066540.html
--- snip ---
While looking at the valgrind warning in
http://kegel.com/wine/valgrind/logs-2008-06-20/vg-oleaut32_tmarshal.txt

Conditional jump or move depends on uninitialised value(s)
   at  serialize_param (tmarshal.c:736)
   by  serialize_param (tmarshal.c:744)
   by  xCall (tmarshal.c:1414)
   by  ???
   by  func_tmarshal (tmarshal.c:1179)
   by  run_test (test.h:449)
   by  main (test.h:498)
 Uninitialised value was created by a stack allocation
   at  test_typelibmarshal (tmarshal.c:762)

The problem happens during a call to this method
where widget is a pointer to an uninitialized pointer
which will receive the pointer to the widget:

interface IKindaEnumWidget : IUnknown
   {
       HRESULT Next(
                    [out] IWidget **widget);

I discovered that the attached patch prevented the problem.
I don't quite understand why; at first glance,
widget is an out parameter from the function,
why would it be dereferenced while serializing
the call?

--- snip ---

Rob Shearman wrote:
http://www.winehq.org/pipermail/wine-devel/2008-June/066571.html

--- snip ---
It's a bug in the typelib marshaller. It doesn't check whether a
VT_PTR type is actually an interface pointer and not access it on
input when the parameter is an [out] parameter. Note that because of
the memory re-use semantics it is legal to access memory passed in to
a remote function, even when the parameter is [out].

I think it's getting close to the time to reimplement the typelib
marshaller on top of NDR functions so that we don't have to implement
these subtleties twice, would improve performance and would reduce the
amount of code.
--- snip ---