[DISCUSSION] Validating regex pattern View as Markdown

Hi,

My concern would be that dynamically creating regex patterns has quite a lot of possible different foot guns and using something like preg_validate/filter_var to prevent warnings seems to not really solve the problem but give a false sense of security.

The purpose I see is not to give a sense of security, but to give
quick feedback whether the pattern is valid or not.

You can end up with a mostly working version which will only trigger the fail path later on depending on user input.

I'm not sure to understand the connection here: validating the regex
pattern itself and matching the pattern with something are two
different things.

It boils down to: If you are not confident that you construct the pattern in a safe way then what would you do if a validation function returns false? You can notify the developer but that is already accomplished with the preg_* warning when an invalid pattern is given. Creating an error page for the user on a warning is also already possible. That's why i'm on the fence whether a validation function does more good or harm.

I don't understand how it could be harmful. Early validation is useful
when it comes to avoiding unnecessary operations if we can already be
sure that it will fail later for obvious reasons. For me, it falls
into the same category as email or URL validation in filter_var.
That's also why I think it would be more appropriate as a flag for
this function rather than a dedicated function.

— Alexandre Daubois

Juliette Reinders Folmer php-internals_nospam@adviesenzo.nl hat am 01.10.2025 19:28 CEST geschrieben:

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

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

Hi,

function is_valid_preg_pattern( $pattern ) {
    $is_valid = true;

    set_error_handler( function () use ( &$is_valid ) { $is_valid = false; return true; }, `E_WARNING` );
    preg_match( $pattern, '' );
    `restore_error_handler()`;

    return $is_valid;
}

Setting and restoring the global error handler to validate a pattern
is exactly what I would qualify as clunky/hacky. Also this requires
internal knowledge on how this works, which feels very wrong for
something like that.

— Alexandre Daubois