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