Re: [DISCUSSION] Validating regex pattern
| From: | Thomas Bley | 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