Re: [Vala] Issues will vala and pulse vapi

[Aaron Paden <aaronbpaden gmail com>]

On Sat, Nov 21, 2015 at 11:07 PM, Evan Nemerson <evan coeus-group com> wrote:
> On Sat, 2015-11-21 at 22:45 -0600, Aaron Paden wrote:
> > On Sat, Nov 21, 2015 at 9:54 PM, Evan Nemerson <evan coeus-group com>
> > wrote:
> > > That's not quite right; the VAPI shouldn't indicate that a *type*
> > > is
> > > "unmanaged"…  it's up to your code to indicate whether an instance
> > > is
> > > unowned.  However, the question is really what the proper way to
> > > destroy an instance is.
> > >
> > > In order to determine how to destroy a struct which doesn't specify
> > > a
> > > destroy_function CCode attribute, Vala will look at the
> > > members.  If
> > > none of the members require destroy or free functions, then Vala
> > > can
> > > assume that simply releasing the memory associated with the struct
> > > itself (i.e., calling g_free on heap-allocated instances, or simply
> > > allowing stack-allocated instances to go out of scope) is
> > > sufficient.
> >
> > Hum. Sourceinfo (and SinkInfo) should not be freed at all, the C APIs
> > that retrieve them give you const pointers.
>
> Then they should return an unowned reference.

Is it possible to do this when the pointer is an argument? These types
are requested and then asynchronously retrieved via callbacks.