Front page | perl.perl5.porters |
Postings from January 2013
On Mon, Jan 14, 2013 at 01:09:56PM +0000, Dave Mitchell wrote:
> On Mon, Jan 14, 2013 at 12:53:02PM +0000, Nicholas Clark wrote:
> > On Mon, Jan 14, 2013 at 07:46:11AM -0500, Jarkko Hietaniemi wrote:
> > > On Monday-201301-14 7:35, Dave Mitchell wrote:
> >
> > > Darn. Foiled by my own former myself. Do I get a prize?
> >
> > A booby prize?
>
> Perhaps $10 for every commit he's ever done ;-)
I don't think that TPF have that much money:
$ git log --format=%ce blead origin/maint-5.8 | grep jhi@iki.fi | wc
12446 12446 136906
> > Check whether SWIG still does this? And if so, submit a patch? :-)
>
> I just had a look at the swig-2.0.9 src code. The only reference to
> MGVTBL is
>
> SWIGRUNTIME void _swig_create_magic(CPerlObj *pPerl, SV *sv, const char *name, int (CPerlObj::*set)(SV *, MAGIC *), int (CPerlObj::*get)(SV *, MAGIC *))
> #endif
> {
> MAGIC *mg;
> sv_magic(sv,sv,'U',name,strlen(name));
> mg = mg_find(sv,'U');
> mg->mg_virtual = (MGVTBL *) malloc(sizeof(MGVTBL));
> mg->mg_virtual->svt_get = (SwigMagicFunc) get;
> mg->mg_virtual->svt_set = (SwigMagicFunc) set;
> ...
>
> which appears to mallocing its own vtable rather than modifying a system
> one.
>
> But I don't understand the code and may have missed something.
That's consistent with my memory of it. IIRC it's relying on the type that
perl defines for VTABLEs to be mutable enough that it can build them up this
way.
Also (yes, "your blog" is not a place to report bugs), I think it leaks that
vtable. By misunderstanding who owns what.
Nicholas Clark
Thread Previous
|
Thread Next