Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84005
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.169 cause and error)
MIME-Version: 1.0
In-Reply-To: <54F077B2.3020103@lsces.co.uk>
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com>
	<CALWK-fghdLMjt5yMMb23mnf0dNt+Mnx_tOYdLopfxLZFZvzTKA@mail.gmail.com>
	<CAEPJdumpCKfdz_gBjBnrH9WVviLp6YtDsSWJXHB+p0Nz8Cs=GA@mail.gmail.com>
	<54F077B2.3020103@lsces.co.uk>
Date: Fri, 27 Feb 2015 15:15:41 +0100
Message-ID: <CAEPJdumCF1xuwd9HVTY7PcpjPaRC8iSdLRgEUveDY4x6KxdjiA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c381c8e7766005101280cd
Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: kontakt@beberlei.de (Benjamin Eberlei)

--001a11c381c8e7766005101280cd
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 27, 2015 at 2:57 PM, Lester Caine <lester@lsces.co.uk> wrote:

> On 27/02/15 13:45, Benjamin Eberlei wrote:
> >>> Drupal admin interface (across the all pages):  One  new E_DEPRECATED
> >>> > > warning, which again seems to catch a real bug - stripslsahes()
> operating
> >>> > > on a boolean.
> >>> > >
> >> >
> >> > All those are due to a bug in substr(), that we see now only thanks to
> >> > proper type identification. There is no reason for substr() to ever
> return
> >> > a boolean. It really needs to be fix to always return a string.
> >> >
> > Yes, weird behavior that substr("", 2, 2); for example returns false. But
> > changing thatis just another evil BC break.
>
> Now I don' think that 'weird' ... Although the correct return should
> perhaps be 'null', but it's long been practice that s there is no result
> we get 'false' so how any places will have a sanity check based on the
> 'false' return?
>

As an example i ported PDepend to work with coercive typehints, this is the
quick and dirty patch:

https://gist.github.com/beberlei/6a5a6b65839d35bb27f0

In longer chains of string handling, i just cast everything to (string)
that could potentially return false here.

Interestingly functions like is_infinite(), is_dir(), is_file() all expect
correct types like float or string here although from the naming convention
"is_something" i would expect it says just false on *anything* else (which
it almost does right now).

The patch also shows that this will lead to weird behavior when the PHP API
is actually wrong like DOMNode::cloneNode() expecting an integer and not a
boolean as argument, even though the PHP Documentation says it should be a
boolean.

I can literally forsee this is the way this kind of code will be fixed.

Imho the problem is that the return values of php internal functions being
string|false will lead to massive consecutive errors when passing this on
to other internal unctions.


>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c381c8e7766005101280cd--