I believe using preg_last_error() and silencing the preg_match error gives a sane way to validate if a regex is acceptable to PCRE.


$invalid_pattern = '/(\d+/';
$dummy_subject = '';

@preg_match($invalid_pattern, $dummy_subject);

$lastError = preg_last_error();

if ($lastError) {
    echo "something was wrong with the regex";
}


Does that not cover detecting valid regexes?

Admittedly getting the exact position of the error would be more than a little useful...

Hi danack. Before when i tested this my PHP shell (psysh) was not showing the PREG_INTERNAL_ERROR value. When i put your code in a file i see this error too. That's great now i don't need a custom error handler. However i still like a separate function for validating the regex. Unfortunately adding a PREG_INVALID_PATTERN won't be backwards compatible now because people might already be checking for $preg === 1 :(
I'm not sure if PREG_INTERNAL_ERROR can happen in other ways that having an invalid pattern. It would be good to make the invalid pattern case explicit.

By the way there is also the return value of preg_match set to false when the pattern match fails. But both the preg_last_error function and the return value can not differentiate between an invalid pattern and another general error.

As you point out danack it would be good to have better information about the error. Perhaps preg_validate_pattern could return an array like:

$return = array('message' => 'missing closing parenthesis', 'offset' => 4);

I don't understand the "PHP is popular therefore it needs a regex validator function" argument...

I would think that a deliberate need to validate a regex would be uncommon outside of an actual regex testing/validation library. Surely most of the time it would be developer error? Writing a bad regex, or incorporating an unknown value that should have been preg_quote()d. Normal error reporting situations address those.

An offset would be nice for a bad regex, but it would also help with PREG_BAD_UTF8_ERROR. And maybe others. What if preg_last_error could be extended with additional information about the error? A by-ref argument for additional information, like an array to be generic or just an int for an offset (pattern or data, depending on the error).

This is more of an inconvenience than a major issue in practice - this can be abstracted into a composer library (which may already exist, I haven't checked).

- I personally want this feature
- The amount of setup and teardown involved is inefficient, and reinventing regex validation is error prone and misses edge cases

I slightly prefer preg_replace over preg_match, because preg_replace will warn about the `/e` modifier being removed and doing nothing, while preg_match doesn't.

                $result = @\preg_replace($pattern, '', '');
                if ($result === false || $result === null) {
                    return \error_get_last() ?? [];
                }
                return null;

I ran into similar issues writing a static analysis plugin that would warn about invalid PCRE regexes passed to preg_match, etc. The code used is 
https://github.com/phan/phan/blob/1.2.3/.phan/plugins/PregRegexCheckerPlugin.php#L41-L58

I presume that providing a wrapper for
pcre_get_compiled_regex_cache_ex() would do the trick; something
like

    preg_validate(string $pattern): int

Closing in favor of <https://github.com/php/php-src/issues/9289>.