Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112393
To: internals@lists.php.net
References: <b845d5bf-63da-d564-1f0f-cc934188d693@aimeos.com>
 <b546b5bf-27f8-62cc-cc4b-d859132998a4@gmx.de>
 <0774c293-afd7-d8b9-175f-217ed600d1ea@aimeos.com>
 <fad4cc49-0f40-53f1-400c-90ff01ffdccb@gmx.de>
 <CAN2symiHHJVGvaLYMD=Qes0Wy06dZRtzPeonNBUWOBRbiTdo5g@mail.gmail.com>
 <CAFPFaMLEdq0+hYkE49YVbcFvCt00rne6roApcoyY4aK=1ZHpuA@mail.gmail.com>
 <8a33dde2-f06c-640d-42bb-3e7af90fd5af@gmail.com>
 <75b5b870-112a-f54e-1fd7-4d425ffa8000@telia.com>
 <A059723E-4320-45B1-B20C-CCC53DF60FD3@gmail.com>
 <1d612903-386e-630d-f91b-fbe7590e41e6@gmx.de>
Message-ID: <10208740-ec3b-7614-9668-b7b580ecb4cf@gmail.com>
Date: Thu, 3 Dec 2020 09:40:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <1d612903-386e-630d-f91b-fbe7590e41e6@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling
From: rowan.collins@gmail.com (Rowan Tommins)

On 03/12/2020 06:52, Stanislav Malyshev wrote:
> PHP functions always returned null on bad parameters, so it's not
> exactly unexpected. 

and

On 02/12/2020 23:49, Christoph M. Becker wrote:
> Just to reiterate, the former behavior was documented[1], and the return
> value was*undefined*.  Instead of returning NULL, the erroneous
> function call could have returned anything, even TRUE.  Relying on
> undefined behavior is bad.


The note on https://www.php.net/manual/en/functions.internal.php says:

 > If the parameters given to a function are not what it expects...

But the prototype on https://www.php.net/manual/en/function.is-file.php is:

>  is_file ( string $filename ) : bool

And the description says only:

> filename:  Path to the file.

While it's clear that passing e.g. an array falls into the scope of that 
general note, it doesn't say anywhere on that page that a string value 
which contains "\0" is "not what it expects", and I don't think I would 
ever have guessed that before reading this thread.

So I stand by my assertion that this behaviour was both undocumented and 
unexpected.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]