Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107605
To: Colin O'Dell <colinodell@gmail.com>,
 PHP Internals <internals@lists.php.net>
References: <CAJaRsPvTvZVWtszNH-uqaOc8487ncGjKdgFikzq60gUhvTNMtQ@mail.gmail.com>
Message-ID: <f18cd106-8b9b-39ca-56d7-2df8876c49d9@gmx.de>
Date: Mon, 21 Oct 2019 17:39:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAJaRsPvTvZVWtszNH-uqaOc8487ncGjKdgFikzq60gUhvTNMtQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: substr with null length
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 20.10.2019 at 17:00, Colin O'Dell wrote:

> Is there any particular reason why the substr() function doesn't accept =
a
> null $length like mb_substr() does?  It seems the behavior to read throu=
gh
> the end of the string can only be controlled by the presence or absence =
of
> the $length parameter:  https://3v4l.org/YpuO1

The reason for this behavioral inconsistency is that when mb_substr()'s
behavior has been changed[1], substr()'s has not.  Due to the subtle BC
break, in my opinion, this shouldn't have been changed in a revision
(happened for 5.4.8); a major version is *more* suitable for such changes.

> I'd be happy to write the RFC [=E2=80=A6]

It seems to me that an RFC would be overkill for this change, but it has
to be discussed.

Tentatively, I'm +0.5 on this change.

[1]
<https://github.com/php/php-src/commit/352a1956b60059f9792cac840d57b184c73=
05667>

=2D-
Christoph M. Becker