Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128761
Subject: Re: [PHP-DEV] [DISCUSSION] Validating regex pattern
To: internals@lists.php.net
References: <CAMU7irLbon_YHUKn01Yy1ks09WO+UkAFXz61EwKw7ROYtMfu3w@mail.gmail.com>
Message-ID: <68DD64BE.5080308@adviesenzo.nl>
Date: Wed, 1 Oct 2025 19:28:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <CAMU7irLbon_YHUKn01Yy1ks09WO+UkAFXz61EwKw7ROYtMfu3w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090403070508010504000106"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------090403070508010504000106
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------090403070508010504000106
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 1-10-2025 11:01, Alexandre Daubois
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAMU7irLbon_YHUKn01Yy1ks09WO+UkAFXz61EwKw7ROYtMfu3w@mail.gmail.com"
      type="cite">
      <div dir="ltr">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.
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>I don't think the second approach would require an RFC.</div>
        <br>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    Some background:<br>
    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].<br>
    <br>
    Involving an unrelated extension (filter), which may be unavailable
    (can be disabled [3]), in the validation just complicates things.<br>
    It also makes the `FILTER_VALIDATE_REGEX_PATTERN` flag highly
    ambiguous as it is unclear against which engine/dialect the regex
    would be validated.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    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()`.<br>
    Maybe there should be a `preg_validate()` function (and a
    `mb_ereg_validate()` function for that matter).<br>
    <br>
    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.<br>
    <br>
    Smile,<br>
    Juliette<br>
    <br>
    <br>
    1: <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/eol-oniguruma">https://wiki.php.net/rfc/eol-oniguruma</a><br>
    2: <a class="moz-txt-link-freetext" href="https://www.php.net/manual/en/function.mb-regex-set-options.php">https://www.php.net/manual/en/function.mb-regex-set-options.php</a><br>
    2: <a class="moz-txt-link-freetext" href="https://www.php.net/manual/en/filter.installation.php">https://www.php.net/manual/en/filter.installation.php</a><br>
    3: <a class="moz-txt-link-freetext" href="https://www.php.net/manual/en/function.preg-last-error.php">https://www.php.net/manual/en/function.preg-last-error.php</a> <br>
  </body>
</html>

--------------090403070508010504000106--