> But PHP uses /e in exactly the same way: The /e is part of the literal regexp.
PHP doesn't have literal regexps as part of the language. The regexps in PHP are string arguments to the preg_* family of functions. Perl has literal regexps. e.g. $var =~ s/$pattern/$replacement/e. If you inject "/e" in to $replacement variable, what happens? I don't know, my Perl is rusty, but I'm thinking that that would be either an unevaluated context, or a syntax error.
> No, /e is not enabled by default.
Only as of 5.5. That doesn't make the decision to enable it by default in the past excusable.
> pcre_callout()
This doesn't look like it has anything to do with /e or code evaluation. It's a callback mechanism that users of the library can use. How it's used is irrelevant, the topic at hand is PHPs behaviour.
> To anyone reading this: Don't use /e with untrusted input, it's not safe.
You missed the point. Programmers can use preg_replace poorly and not know that /e even exists. That was one point in the article: that this little function has a surprising and potentially dangerous feature. Just saying "oh well, don't use untrusted input" is naive.
> PHP doesn't have literal regexps as part of the language.
It doesn't really change anything. Instead of using / to delimit the parts each part is sent as an argument to the function.
> Is/$pattern/$replacement/e. f you inject "/e" in to $replacement variable, what happens? I don't know
In PHP that regex would look like preg_replace("/$pattern/e", $replacement), so injecting a /e in the replacement doesn't do anything - it has to be in the pattern not in the replacement.
> Only as of 5.5. That doesn't make the decision to enable it by default in the past excusable.
No, it was never enabled by default. Why do you think it was enabled by default? That wouldn't even make sense.
> It's a callback mechanism that users of the library can use. How it's used is irrelevant, the topic at hand is PHPs behaviour.
How it's used is to - drumroll - enable /e - the callback runs the PHP function that executes the code whenever it sees a place where the /e should activate. i.e. /e is certainly part of the preg C library.
It wasn't a rant.
> But PHP uses /e in exactly the same way: The /e is part of the literal regexp.
PHP doesn't have literal regexps as part of the language. The regexps in PHP are string arguments to the preg_* family of functions. Perl has literal regexps. e.g. $var =~ s/$pattern/$replacement/e. If you inject "/e" in to $replacement variable, what happens? I don't know, my Perl is rusty, but I'm thinking that that would be either an unevaluated context, or a syntax error.
> No, /e is not enabled by default.
Only as of 5.5. That doesn't make the decision to enable it by default in the past excusable.
> pcre_callout()
This doesn't look like it has anything to do with /e or code evaluation. It's a callback mechanism that users of the library can use. How it's used is irrelevant, the topic at hand is PHPs behaviour.
> To anyone reading this: Don't use /e with untrusted input, it's not safe.
You missed the point. Programmers can use preg_replace poorly and not know that /e even exists. That was one point in the article: that this little function has a surprising and potentially dangerous feature. Just saying "oh well, don't use untrusted input" is naive.