|We don't bite newbies here... much|
Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
I agree, the fix is not finished yet. I suspect that the patch works because the rest of the function "mistakes" the private string for a public string, so to speak, and that the test suite passes because either the function is never invoked on a capture variable or because no variable with PERL_MAGIC_sv passes through that function which lacks a private string. Note that the patch doesn't affect all magic variables, just those with PERL_MAGIC_sv -- which is only one type among many, despite the name. From perl.h:
Nevertheless, it's useful to have isolated the problematic section of code.
I managed to hunt down some prior discussion: http://rt.perl.org/rt3//Public/Bug/Display.html?id=60472.
Nicholas Clark had this to say:
POK shouldn't be on for something with GMG. It should only be pPOK, so that any calls to SvPV() etc call into Perl_sv2pv_flags(), and the get magic is triggered.
(GMG is "get magic".) Based on Nick's post, I think we can confirm that the fact that $1 leaves this function with the SVf_POK flag on is a bug.
demerphq had this to say with regards to why $1 doesn't carry the READONLY flag:
Turns out that this is deliberate, as some pluggable regex engines allow for a writable $1.
Aevar patched this in quite some time ago.
So I think at this points its a bug in Encode, but I couldn't figure out how to fix it in the time I had available.
Perhaps we have tracked down this "bug in Encode".
Incidentally, this bug is a regession in Perl 5.10. Perl 5.8.8 doesn't have this problem.