Tassilo Parseval <[EMAIL PROTECTED]> writes:
>On Thu, Oct 30, 2003 at 11:13:47AM +0000 Nick Ing-Simmons wrote:
>
>> Sisyphus <[EMAIL PROTECTED]> writes:
>> >Tassilo von Parseval wrote:
>
>> >> It is. If you have code like
>> >>
>> >> {
>> >> my $var = my_xsub();
>> >> ...
>> >> }
>> >>
>> >> Mortals are just variables that clean up themselves
>> >> when their reference count goes to zero.
>> >>
>> >
>> >I still question that - and hope that in so doing I don't raise your
>> >anger. (That's not what I'm trying to do :-)
>>
>> You are right.
>>
>> The sv_2mortal _IS_ needed in the
>>
>> void
>> my_xsub()
>> CODE:
>> {
>> ST(0) = sv_2mortal(newSVpv(string,strlen(string));
>> XSRETURN(1);
>> }
>>
>> case.
>>
>> But it is inserted for you SV * return case:
>>
>> {
>> RETVAL=newSV...;
>> }
>> #line 25 "Foo.c"
>> ST(0) = RETVAL;
>> sv_2mortal(ST(0));
>> }
>> XSRETURN(1);
>> }
>
>Hmmh, indeed. I peeked at xsubpp and it looks as though this is a
>special case:
>
> elsif ($expr =~ /^\s*\$arg\s*=/) {
> # We expect that $arg has refcnt >=1, so we need
> # to mortalize it!
> eval "print qq\a$expr\a";
> warn $@ if $@;
> print "\tsv_2mortal(ST(0));\n";
> print "\tSvSETMAGIC(ST(0));\n" if $do_setmagic;
> }
>
>The typemap entry for 'SV*' expands to
>
> $arg = $var
>
>However, doing
>
> char *
> my_xsub()
> CODE:
> RETVAL = strdup(string);
> OUTPUT:
> RETVAL
>
>will leak since the returned SV is not mortalized (and the copy of
>'string' thus never freed).
That leaks for strdup() reasons, not for SV leak:
#line 18 "Foo.xs"
{
RETVAL=strdup(string);
}
#line 47 "Foo.c"
sv_setpv(TARG, RETVAL); XSprePUSH; PUSHTARG;
}
XSRETURN(1);
}
That does not "leak" as it uses the TARG scheme.
>
>I think this is one good reason for sticking to one style of handling
>return values in XS since they differ quite significantly.
Agreed.
>I prefer the
>explicit manipulation of the return stack by feeding it my manually
>constructed SV's.
So do I.
>That way, I can be sure that each scalar has the
>characteristics it is supposed to have.
>
