Re: [DISCUSSION] Validating regex pattern

From: Date: Wed, 01 Oct 2025 18:35:47 +0000
Subject: Re: [DISCUSSION] Validating regex pattern
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-128763@lists.php.net to get a copy of this message
> Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl> hat am 01.10.2025 19:28 > CEST geschrieben: > > > On 1-10-2025 11:01, Alexandre Daubois wrote: > > > Two propositions emerged from the issue: either create a dedicated > > "preg_validate()" function, or add a new flag to "filter_var()", namely > > FILTER_VALIDATE_REGEX_PATTERN. > > > > I would be in favor of the latter. The approach and implementation would surely be > > simpler. I don't feel like we should do advanced error management. Knowing if a pattern is > > valid or not would suffice for the vast majority of cases. > > > > I don't think the second approach would require an RFC. > > > I'd love to see more robust ways to validate regexes, but I do not like this proposal, as > any solution involving the filter extension feels wrong. > > Some background: > 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]. > > Involving an unrelated extension (filter), which may be unavailable (can be disabled [3]), in > the validation just complicates things. > It also makes the FILTER_VALIDATE_REGEX_PATTERN flag highly > ambiguous as it is unclear against which engine/dialect the regex would be validated.. > > It is my opinion that any regex pattern validation should be done in the same extension realm > as the extension which will use the regex. > > 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(). > Maybe there should be a preg_validate() function (and a > mb_ereg_validate() function for that matter). > > 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. > > Smile, > Juliette > > > 1: https://wiki.php.net/rfc/eol-oniguruma > 2: > https://www.php.net/manual/en/function.mb-regex-set-options.php > 2: https://www.php.net/manual/en/filter.installation.php > 3: https://www.php.net/manual/en/function.preg-last-error.php > https://www.php.net/manual/en/function.preg-last-error.php > currently we have: @preg_match('/a[/', ''); echo preg_last_error_msg(); // gives: Internal error The real error would be "Compilation failed: missing terminating ] for character class at offset 2". So having a better error message would help. JS has a RegExp class that can be combined with try-catch: const re = new RegExp("ab+c", "i"); const re = new RegExp(/ab+c/, "i"); Go has: r, err := regexp.Compile("p([a-z]+)ch") Rust has: let re = Regex::new(r"unclosed("); So having a RegExp class in PHP would make sense to me. Regards Thomas

« previous php.internals (#128763) next »