Front page | perl.perl5.porters |
Postings from May 2013
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 ClarkThread Previous | Thread Next