Hi, > Historically, PHP supported three regex engines (POSIX, PCRE, Oniguruma). The > POSIX engine was dropped in PHP 7.0 and there is a draft RFC to drop support > for Oniguruma [1], however, that still means that at this time PHP supports > two different regex engines, which each have their own criteria for when a > regex is a valid pattern, and for Oniguruma supports a multitude of regex > dialects [2].
I wasn't aware of that. Thanks for the info! > It also makes the `FILTER_VALIDATE_REGEX_PATTERN` flag highly ambiguous as it > is unclear against which engine/dialect the regex would be validated. Indeed, the multi-engine "issue" makes it clear that it would be ambiguous. > Maybe the error code flags returned via `preg_last_error()` [4] should be > made more specific to allow for detecting when a regex function failed due to > an error in the regex. > Maybe the extensions should get a "throw on invalid regex" option, either via > an ini flag, a new function parameter or via an existing function like > `mb_regex_set_options()`. I like the first solution, I like the second one even more. It would be aligned with JSON_THROW_ON_ERROR. > I'm not sure what the best solution is, but going with an illogical solution > just to try and avoid the RFC process is not the way to go IMO. The purpose isn't to avoid the RFC process, I'll write one if necessary. I just want to gather opinions and deduct if it's necessary :) — Alexandre Daubois
