[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