[perl #117793] Extend SvREFCNT* to work on any perl variable type

On Mon May 13 11:06:50 2013, nicholas wrote:
> On Mon, May 13, 2013 at 01:36:06PM -0400, bulk88 wrote:
> > Nicholas Clark wrote:
> > >
> > > 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
> >
> > The refcount checkers from Perl lang are useful to prove in a test
> that
> > a leak was fixed.
> 
> Agree, in that I could see that the perl core is reading reference
> counts in
> tests to check them. But not changing them. I went for a look with
> grep.cpan.me, and as far as I can tell the pretty much only place
> doing this
> in tests is the perl core. But the core doesn't need to install self-
> test
> infrastructure, just to have it available during testing.
> 
> (That's not an argument that everything must change. Just a thought
> that
> things are not as constrained as they might seem)

So should we be removing (or deprecating) the SvREFCNT_*() modifiers
from Devel::Peek, but keep SvREFCNT() itself?

Or nuke them all, since they're available (if deliberately undocumented)
in Internals?

Tony


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=117793

• [perl #117793] Extend SvREFCNT* to work on any perl variable type by Tony Cook via RT
• [perl #117793] Extend SvREFCNT* to work on any perl variable type by Tony Cook via RT
• [perl #117793] Extend SvREFCNT* to work on any perl variable type by Tony Cook via RT
• [perl #117793] Extend SvREFCNT* to work on any perl variable type by Tony Cook via RT