-
Notifications
You must be signed in to change notification settings - Fork 560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use re 'eval' does not capture lexical environment %^H like eval() does, breaking charnames #20950
Comments
Turns out I don't even need all this overloading business:
|
Refs in the hints hash
|
I still consider that a bug tho, at the very least it should give a better error message. Although there is a bunch of weirdness with this case. Returning a charnames string from a (?{ ... }) doesn't make a lot of sense to me (maybe for $^R). I assume mauke wanted (??{ ... }) (which still has the same issue). But the other thing is why not just call charnames in the double quoted string? Anyway, imo at the very least this should produce a better error message. |
It looks like I think |
I can try to take a look, but i suspect this is more appropriate for @iabyn to pick up. |
The code related to this seems to be in the call checker for Lines 12214 to 12225 in 0d292c7
Then the hintseval OP puts that hash on the stack: Lines 5007 to 5012 in 0d292c7
And eval knows to take it off the stack based on the OPpEVAL_HAS_HH flag: Lines 5052 to 5054 in 0d292c7
|
Module: charnames
Description
You can get
charnames
to blindly call a stringified coderef as if it were a sub, causing bizarre errors.Steps to Reproduce
Result:
Expected behavior
To be honest, I'm not sure. I don't really understand what this code does; it was reduced from Regexp::Grammars. I wasn't expecting an error, though.
Perl configuration
The text was updated successfully, but these errors were encountered: