Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: utf8::upgrade and $1

by creamygoodness (Curate)
on Aug 31, 2009 at 05:25 UTC ( [id://792291]=note: print w/replies, xml ) Need Help??


in reply to Re: utf8::upgrade and $1
in thread utf8::upgrade and $1

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:

#define PERL_MAGIC_sv '\0' /* Special scalar variable */ #define PERL_MAGIC_overload 'A' /* %OVERLOAD hash */ #define PERL_MAGIC_overload_elem 'a' /* %OVERLOAD hash element */ ...

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.

Replies are listed 'Best First'.
Re^3: utf8::upgrade and $1
by ikegami (Patriarch) on Aug 31, 2009 at 18:06 UTC

    I think we can confirm that the fact that $1 leaves this function with the SVf_POK flag on is a bug.

    Yes.

    demerphq had this to say with regards to why $1 doesn't carry the READONLY flag:

    Not a problem for my solution. The setter called via mg_set after the upgrade will throw an error if appropriate.

    Turns out that this is deliberate, as some pluggable regex engines allow for a writable $1.

    That means that upgrading $1 might have no effect or might upgrade the entire source string in those engines, but I don't see that as a problem. Side-effects are expectedintended when playing with magical variables.

    Incidentally, this bug is a regession in Perl 5.10. Perl 5.8.8 doesn't have this problem.

    That would explain the presence of sv_utf8_upgrade_nomg.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://792291]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (5)
As of 2024-03-29 08:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found