develooper Front page | perl.perl5.porters | Postings from September 2011

typemap for AV* leaks

Thread Previous | Thread Next
From:
Steffen Mueller
Date:
September 8, 2011 23:13
Subject:
typemap for AV* leaks
Message ID:
4E69AE62.5080403@cpan.org
On 09/09/2011 05:16 AM, Eric Brine via RT wrote:
> On Thu Sep 08 16:57:13 2011, tonyc wrote:
>> On Thu, Sep 08, 2011 at 04:17:52PM -0700, Eric Brine wrote:
>>> When using return type AV* in XS, the typemap wraps the array in a
>>> reference, but leaves the refcount too high.
>>
>> This is documented in perlxs:
>>
>> This is quite useful as it usually improves readability. While
>> this works fine for an C<SV *>, it's unfortunately not as easy
>> to have C<AV *>  or C<HV *>  as a return value. You I<should>  be
>> able to write:
>>
>>    AV *
>>    array()
>>        CODE:
>>            RETVAL = newAV();
>>            /* do something with RETVAL */
>>        OUTPUT:
>>            RETVAL
>>
>> But due to an unfixable bug (fixing it would break lots of existing
>> CPAN modules) in the typemap file, the reference count of the C<AV *>
>> is not properly decremented. Thus, the above XSUB would leak memory
>> whenever it is being called. The same problem exists for C<HV *>.
>>
>
> Thanks. Closing ticket.

Sending this only to the list with the [...] RT tag removed in order not 
to reopen the ticket.

Basically, we've committed to not change the typemap any more at all for 
fear of breaking backward compatibility. I suppose that's a reasonable 
decision as far as the current (and ancient) typemap goes. But it has 
various bugs. One is the above, others have been diagnosed by Marc 
Lehmann, I think at least one of which means that it's unduly hard to 
write XS that handles perl strings correctly.

Wouldn't it be nice if we figured out a way to solve this problem?

Somehow, I feel that with the typemap related tools we now have in core 
with ExtUtils::Typemaps* all the puzzle parts for a solution are 
available. It just needs somebody to put them together. EU::Typemaps can 
be used to munge typemaps to your heart's content, and can be subclassed 
to provide more/new/different/overriding defaults.

Any ideas? Takers? I'd just love to have a backward compatible way to 
fix typemaps.

--Steffen

* and configure_requires if worse comes to worst.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About