On Thu Jan 26 10:06:00 2012, demerphq wrote: > Sorry to nag but this doesn't seem to test that 'no overloading' > stopped a qr => sub { qr/bcd/ } overload from firing... Well, I didn’t touch that part of the code. :-) On the other hand, I did stop concat-overloading-return-qr from working with eval groups. /(other stuff)$overloaded(other stuff)/ is lamentably undertested. I’ve just discovered a security hole: use overload fallback => 1, '.' => sub { my $x = qr/(?{})/; $_[2] ? "$_[1]$x" : "$x$_[1]" }; $o = bless[]; $foo = '(?{})'; "" =~ /foo$o$foo/; Without my patch applied, that gives me: Eval-group not allowed at runtime, use re 'eval' in regex m/foo(?^:(?{}))(?{})/ at - line 11. Add an $x stringification in the overload sub: use overload fallback => 1, '.' => sub { my $x = qr/(?{})/; "$x"; # <-- here $_[2] ? "$_[1]$x" : "$x$_[1]" }; $o = bless[]; $foo = '(?{})'; "" =~ /foo$o$foo/; and $foo is interpolated and compiled without error. For my patch to stop qr// stringification inside an overload method from working with eval groups seems like a good thing to me. The PL_reginterp_cnt hack in sv_2pv_flags seems to have been added for regcomp’s sake to begin with. So why wasn’t it just added to regcomp? For overloading? The commit that added it (2cd61cdbd) mentions no such thing. My patch moves that hack into regcomp, where it arguably belongs. It stops ‘use overload "."=>sub { qr/(?{})/ }’ from working when called from /foo$overload/, but for security’s sake I don’t think it *should* work, and it’s an accident that it ever worked. -- Father Chrysostomos --- via perlbug: queue: perl5 status: resolved https://rt.perl.org:443/rt3/Ticket/Display.html?id=108780Thread Previous | Thread Next