Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128555
Date: Tue, 26 Aug 2025 11:15:14 +0100 (BST)
To: "Christoph M. Becker" <cmbecker69@gmx.de>
cc: youkidearitai <youkidearitai@gmail.com>, 
    php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV][DISCUSSION] Deprecate mbregex in PHP 8.6 and maintenance
 version
In-Reply-To: <8d1d90e2-b2db-421a-babe-f915dc06b76d@gmx.de>
Message-ID: <d7e178e0-6040-e7aa-0ef2-ff011815ff44@php.net>
References: <CAEPPVa3S+CeCzK+EY7CY6B=C5Mt0ePKq7E-HQwSR=fQ0zap1Bg@mail.gmail.com> <CAEPPVa3Y41+_6TD6Ae8Sph10USuTC0w-tqB3N+kc1wh=nmF5CA@mail.gmail.com> <8d1d90e2-b2db-421a-babe-f915dc06b76d@gmx.de>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: derick@php.net (Derick Rethans)

On Mon, 25 Aug 2025, Christoph M. Becker wrote:

> On 25.08.2025 at 09:26, youkidearitai wrote:
> 
> > I improvement this RFC. https://wiki.php.net/rfc/eol-oniguruma
> > 
> > Added more information about maintenance versions. What do you think 
> > about Oniguruma maintenance ended. Please watch and feel free to 
> > comment.
> 
> First, thank you for caring about this!  I agree that we need a long 
> term solution for this issue.  As I understand it, Oniguruma's 
> greatest advantage over PCRE2 is that it supports other character 
> encodings than Unicode and ANSI, so deprecating mbregex might be a 
> problem for some users.

Yes, but I think Yuya mentioned somewhere else (I can't find it now) in 
an earlier discussion, that many of these users now also moved to UTF-8. 
It would also be possible to rewrite these uses from using mbregex to 
UConverter::convert+pcre.

Incidently, icu also has a regular expression engine, but of course 
that'll operate on UTF-16, and we'd have to create a full new 
implementation for that:

- https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/uregex_8h.html

> Still, the alternative would likely be to bundle liboniguruma, and I 
> don't think that would be a good idea.  So deprecating mbregex as of 
> PHP 8.6.0 seems prudent; if there would be lots of objections, we 
> could still reconsider.

I agree with that.

> Now I wonder how much trouble it would be to separate mbregex from 
> ext-mbstring.  If that can be done with a reasonable amount of work, 
> that would likely be the best course of action (in addition to 
> deprecating mbregex).  We could than move the extension to PECL/PIE, 
> and let users deal with it (I'm not happy what happened to ext-imap, 
> but it's still better than relying on an unmaintained library from a 
> bundled extension).

Seeing code like in mbstring.c

#ifdef HAVE_MBREGEX
    PHP_MINIT(mb_regex) (INIT_FUNC_ARGS_PASSTHRU);
#endif

And:

php_mbregex.h:PHP_MINIT_FUNCTION(mb_regex);
php_mbregex.h:PHP_MSHUTDOWN_FUNCTION(mb_regex);
php_mbregex.h:PHP_RINIT_FUNCTION(mb_regex);
php_mbregex.h:PHP_RSHUTDOWN_FUNCTION(mb_regex);
php_mbregex.h:PHP_MINFO_FUNCTION(mb_regex);

makes it feel that it already sort-of operates as a sub-extension, and 
it wouldn't be *too* much work. But it will still be work. Is it worth 
it?

cheers,
Derick
-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social