Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84022
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain damz.org designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ED7146272E04A47B986ED49E771E347D3111ACD63@Ikarus.ameusgmbh.intern>
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com>
	<CALWK-fghdLMjt5yMMb23mnf0dNt+Mnx_tOYdLopfxLZFZvzTKA@mail.gmail.com>
	<4ED7146272E04A47B986ED49E771E347D3111ACD63@Ikarus.ameusgmbh.intern>
Date: Fri, 27 Feb 2015 16:53:33 +0100
Message-ID: <CALWK-fik9mKAd=GymAocpq0rJOaGhPnvfD+PDA-5BKwkh4wHGA@mail.gmail.com>
To: Christian Stoller <stoller@leonex.de>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122e8b6eb29a7051013def9
Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: damz@damz.org (Damien Tournoud)

--089e0122e8b6eb29a7051013def9
Content-Type: text/plain; charset=UTF-8

Hi Christian,

On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller <stoller@leonex.de>
wrote:

> It is not a bug. FALSE as a return value of substr() is the identificator
> for an error (e.g. invalid arguments), as it is stated in the
> documentation:
> [...]
>

"It is documented that way" and "it is not a bug" are two very different
things.

In that case, the semantics of `substr()` are just wrong. It makes a lot
more sense for a sub-string function to silently allow reading before the
beginning and past the end of a string.

Moreover, the *conditions* under which `substr()` returns FALSE looks
completely arbitrary, see http://3v4l.org/gtFjk -- in a nutshell: so it is
OK to read past the beginning, it is OK to try to get more characters than
the string has, but it is NOT OK to try to start reading past the end?

This behavior is unpredictable, and as a consequence using `substr()`
properly would require a lot of painful and unnecessary up-front checks. It
traditionally did not matter, because of the fluid scalar casts. But if we
want now to introduce stricter casts, we are going to have to tackle this
problem, we cannot just dismiss it as a programming error.

Damien

--089e0122e8b6eb29a7051013def9--