note
creamygoodness
<p>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
<c>PERL_MAGIC_sv</c> passes through that function which lacks a private string. Note
that the patch doesn't affect all magic variables, just those with
<c>PERL_MAGIC_sv</c> -- which is only one type among many, despite the name.
From perl.h:
<c>
#define PERL_MAGIC_sv '\0' /* Special scalar variable */
#define PERL_MAGIC_overload 'A' /* %OVERLOAD hash */
#define PERL_MAGIC_overload_elem 'a' /* %OVERLOAD hash element */
...
</c>
<p>Nevertheless, it's useful to have isolated the problematic section of code.
<p>I managed to hunt down some prior discussion:
[http://rt.perl.org/rt3//Public/Bug/Display.html?id=60472].
<p>Nicholas Clark had this to say:
<blockquote>
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.
</blockquote>
<p>(GMG is "get magic".) Based on Nick's post, I think we can confirm that the
fact that $1 leaves this function with the <c>SVf_POK</c> flag on is a bug.
<p>[demerphq] had this to say with regards to why $1 doesn't carry the
<c>READONLY</c> flag:
<blockquote>
Turns out that this is deliberate, as some pluggable regex engines
allow for a writable $1.</blockquote>
<blockquote>Aevar patched this in quite some time ago.</blockquote>
<blockquote>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.
</blockquote>
<p>Perhaps we have tracked down this "bug in Encode".
<p>Incidentally, this bug is a regession in Perl 5.10. Perl 5.8.8 doesn't have this
problem.
792157
792272