SVs_OBJECT now has a meaning on pad names, other than its meaning elsewhere.
Test::LeakTrace allows a leaked scalar (even a pad name) to be passed to user code. And that allows pad names to reach all sorts of code paths that would not reach under usual circumstances.
I don’t want to break Test::LeakTrace, since it is an extremely useful module that I have even used to track down core bugs.
I could change the definition of SvOBJECT, and have it check the pad name flags, too. But that would make all uses of SvOBJECT slightly slower. I wouldn’t mind doing that, though, if there were no other obvious solution.
For me, the obvious fix is to separate pad names from SVs. I have talked about this several times in the past, but never actually gotten to it. I think it needs to be done anyway, because the conflation makes both pad names and SVs more complex than they need to be.
I have outlined how the pad names could be done in <http://www.nntp.perl.org/group/perl.perl5.porters/;email@example.com>.
On Sun, Nov 16, 2014 at 04:49:36PM -0800, Father Chrysostomos wrote:
For me, the obvious fix is to separate pad names from SVs.
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.
Migrated from rt.perl.org#123223 (status was 'resolved')
Searchable as RT123223$
The text was updated successfully, but these errors were encountered: