Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112361
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>
 <29529061-dc71-c759-590a-b4786936f8c5@aimeos.com>
 <96e40442-a649-f9af-a0cc-dd43cfd1bd0c@gmx.de>
 <CAF+90c-xkV0PUBmOysrQYKoH2-muw0RHSamNJmM27HX1n+Px1Q@mail.gmail.com>
 <d798030e-e383-2ae5-f84c-d1175858970d@gmail.com>
Message-ID: <f9f8d24b-2cd4-b43f-bea8-1901d01c67c3@gmail.com>
Date: Tue, 1 Dec 2020 20:35:14 +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: <d798030e-e383-2ae5-f84c-d1175858970d@gmail.com>
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 01/12/2020 20:06, Stanislav Malyshev wrote:
>> is broken is a great illustration of that. PHP 8 makes it obvious 
>> that the
>> cited code is incorrect.
>
> But it's not incorrect. if is_file("abc\0") returns false, it's 
> correct - "abc\0" is not a correct filename, so I expect it to return 
> false. It does exactly what I need, so it's correct. 


The posted code is correct under a theoretical version of is_file() that 
returns false for that input, but it is incorrect for all versions of 
PHP after PHP 5.4, since they return null (as shown by the sample posted 
by George: https://3v4l.org/7E2mv) so the ===false condition will not be 
met.

I think we can all agree that the previous behaviour was less than ideal 
- the NULL return value was undocumented and unexpected, and the wording 
of the Warning was pretty vague.

If I'd never seen this discussion, I think my assumption would be that 
invalid input would simply return false in this particular case - if the 
path is logically impossible, then it's not a file. However, I wonder if 
there other functions also use this undocumented "file path" input type, 
where there isn't such an obvious safe return value, and throwing an 
exception is more justifiable.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]