[similar message was originally posted to clp.misc on Aug 9]

I've run into something that looks like a bug in the T_IN, T_OUT, 
and T_INOUT stub code in lib/ExtUtils/typemap, but I'm not 
sure.

Here's a (slightly reformatted) excerpt from the typemap file:

T_IN
        {
            GV *gv = newGVgen("$Package");
            if ( do_open(gv, "<&", 2, FALSE, 0, 0, $var) )
                sv_setsv($arg, sv_bless(newRV((SV*)gv), 
                                        gv_stashpv("$Package",1)));
            else
                $arg = &PL_sv_undef;
        }


What is the rationale behind constructing a blessed object ($$arg) with
an apparent refcount of "3" ( +1 for newGVgen, +1 for newRV, and +1 
for sv_setsv)?

It seems like "1" would have been the obvious choice here, which is 
easily accomplished (and similar to what's done in ext/IO/IO.xs):

T_IN
        {
            GV *gv = newGVgen("$Package");
            if ( do_open(gv, "<&", 2, FALSE, 0, 0, $var) )
                sv_setsv($arg, sv_bless(newRV_noinc((SV*)gv), 
                                        gv_stashpv("$Package",1)));
            else
                $arg = &PL_sv_undef;
            hv_delete(GvSTASH(gv), GvNAME(gv), GvNAMELEN(gv), G_DISCARD);
        }


Obviously it is possible to override the default typemap; I am just
unable to see any advantage that the current T_IN code provides.

Any help is much appreciated.
Thanks.

-- 
Joe Schaefer

Reply via email to