develooper Front page | perl.perl5.porters | Postings from May 2013

Re: [perl #117793] Extend SvREFCNT* to work on any perl variabletype

Thread Previous
From:
Karl Williamson
Date:
May 13, 2013 15:11
Subject:
Re: [perl #117793] Extend SvREFCNT* to work on any perl variabletype
Message ID:
519102A3.3050605@khwilliamson.com
On 05/13/2013 09:03 AM, Nicholas Clark wrote:
> On Mon, Apr 29, 2013 at 09:02:50AM +1000, Tony Cook wrote:
>> On Sun, Apr 28, 2013 at 02:39:25PM -0700, Dominic Hargreaves wrote:
>>> "I recently discovered that Devel::Peek's SvREFCNT, SvREFCNT_inc
>>> and SvREFCNT_dec functions are not as flexible as the XS functions that
>>> they wrap.  In XS where you wish to get the reference count of an hash
>>> your HV * pointer will cast to an SV * when passed as an argument to
>>> SvREFCNT().  In Perl using Devel::Peek:SvREFCNT(%m) does not return the
>>> reference count of %m, but rather treats %m as a list of arguments to
>>> the function causing a runtime error.  I believe the intent of the code was
>>> to return the reference count of the parameter passed and the difference
>>> between Perl Prototypes and C casting was overlooked.
>>>      A small patch (attached) will extend these three functions to
>>> work on any perl variable type.  This could break code in cases where
>>> users expect an array of one member passed to these functions to operate
>>> on that only member of the array, but for all other data types (and
>>> arrays of any other length) these functions currently croak.  Possibly a
>>> new family of functions is warranted to maintain reverse compatibility
>>> in the single element array case in the existing functions, but it is
>>> not my place to make that judgement."
>>
>> Or we could just deprecate/remove them.
>
> Yes. It's always going to be possible for people to use (or write) code
> to mess with the internals, such as reference counts.
>
> But I'm really not convinced that we should be offering documented functions
> in the default installation which offer such dangerous direct unguarded
> access to the internals. If people want to live dangerously, they should
> at least have to install an appropriate module from CPAN.
>
> Nicholas Clark
>

+1

Thread Previous


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