Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112355
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>
Message-ID: <8a33dde2-f06c-640d-42bb-3e7af90fd5af@gmail.com>
Date: Tue, 1 Dec 2020 11:57:31 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CAFPFaMLEdq0+hYkE49YVbcFvCt00rne6roApcoyY4aK=1ZHpuA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> So why having is_file()/is_dir() throw a warning for the past 8 years
> (since PHP 5.4) a non-issue? Because by that logic it shouldn't

Warning is a debugging functionality. Throwing is breaking the app and 
stopping the whole process. There's a fundamental difference between the 
two.

> Would it have been fine if this would have been a TypeError as it was
> originally intended?

It's not a type error. PHP does not support such types. "string that is 
a valid filename" is not a type in PHP, thus TypeError would be misleading.

> Is a warning fine because null bytes indicate a potential attack as in no
> sane
> context should null bytes be passed around?

A warning is fine because it does what it's supposed to do - fails the 
is_file check (which is literally only there to check if this string 
specifies a valid filename) while not breaking the app. Exception breaks 
the app.

So what we'll be seeing very soon is people creating userspace safe_is_* 
wrappers that would work around this "functionality", working against 
the language instead of being helped by it. This is not how it should be.
-- 
Stas Malyshev
smalyshev@gmail.com