Re: [PATCH] Use Glib's infrastructure for attaching magic



Kevin Ryde <user42 zip com au> writes:

Florian Ragwitz <rafl debian org> writes:

     data_sv = newSViv (PTR2IV (wrapper));
-    sv_magic ((SV *) dummy_cv, 0, PERL_MAGIC_ext, (const char *) data_sv, 0);
+    gperl_attach_mg ((SV *) dummy_cv, data_sv);

Incidentally, that data_sv looks like it's leaked on DESTROY -- with
or without this different magicness.

Quite true. I fixed that in a follow-up commit which i didn't include in
the series mailed to the list because it's in principle unrelated to
this. I'll push that when this series goes in in one form or another.

Is there any reason it's not the "wrapper" pointer directly put into
the magic?  It holds any pointer can it, doesn't have to be an SV*?

I wondered that too. I briefly looked over how it's used and it turned
out to be used as a return-by-reference value in some glib callback. It
still seemed like it might be either unnecessary or leaking soemwhere,
but again, the leak already exists and the purpose of these changes is
not to fix them.

Likewise the "stuff" in GtkTreeSortable.xs.  But except the
newCONSTSUB is presumably a much bigger leak if it's a permanent
addition to the symbol table.

On versions of perl that aren't buggy in this regard, it's not a leak.

Could it get away with the same subr name each time?  Or is there an
easy way to make an anon sub?

Probably, but again: not what's being tried to be achieved here.

Attachment: pgpD2Gc33lHiC.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]