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