Same exact behavior for these functions too, with same misleading error message, same undocumented NULL return value and triggered E_WARNING:

is_writable() / is_writeable()
is_readable()
is_executable()
is_file()
is_dir()
is_link()

Again, in my opinion:

- These functions should do their business silently by testing their specific case on the submitted string; no further diagnostic error should be emitted, as this could require a much more articulated API for being useful to a running program. For example, programs may wish to test for the specific structure of the path, URL, network resource, etc. or test for permissions, or test for remote server accessibility, etc. and all this would requires specific API and feedback.

- Misleading error message still there.

- Unexpected undocumented NULL return value.

1. No, file_exists does not test valid paths. It tests if a "file" exists. The presumption is that the path you are giving is valid, because if not then it couldn't possibly exist. And no filesystem I've heard of allows NULs.

2. "expects parameter %d to be a valid path, string given" is a bit unusual. The message says that because the check is done during the parameter check phase that every function uses, and "a path" is a certain type of parameter that the engine supports. That also means altering the message for this particular case may not be easy.

3. http://php.net/manual/en/functions.internal.php

don't change the fact that it is not helpful to spit any warning for file_exists() and friends for whatever reason (open_basedir as example) because sane environments are running with error_reporting E_ALL and display_errors off so you are forced in way too many situations typing @file_exists() while i don't care in the code why i can't access a given file, that's why i ask file_exists() and i want a true/false

> An error could possibly be triggered if and only if 
> the argument is something badly wrong like an object or an array

with strict_types you get a type error and then it's okay because you optet-in for that behavior and it's catchable

> […] and "a path" is a certain type of parameter that the engine
> supports.

To clarify: a path is a string which does not contain NUL bytes[1].
We may consider to introduce it as pseudo-type in the documentation.

> […] it is not helpful to spit any warning for file_exists() and
> friends for whatever reason (open_basedir as example) […]
> […] i want a true/false

So you prefer to be lied to?  (/etc/passwd may very well exist…)

Anyhow, changing the behavior of file_exists() and maybe other
filesystem function would require the RFC process[2].

[1] <https://github.com/php/php-src/blob/php-7.2.6/README.PARAMETER_PARSING_API#L65-L66>
[2] <https://wiki.php.net/rfc/howto>

> So you prefer to be lied to? (/etc/passwd may very well exist?)

for my application it don't exist and spit warnings to the errorlog is not helpful at all

"Warning: This function returns FALSE for files inaccessible due to safe mode restrictions" - no matter if safe_mode now is gone - it has to return true in case i can access a file and in every other false

what currently happens is that code which was not tested in a chroot or open_basedir environemnt spits the logfiles full with warning for file_exists('../path'); and enforces developers to spit the code full of @file_exists() while verybody knows the @ is typically the wrong solution

I very agree with the OP - it's completely unexpected to get such a result (null and not helpful warning). 

> No, file_exists does not test valid paths.
Ok, could you tell the community which function tests for valid paths?

This is fixed as of PHP 8.0.1[1].

[1] <https://3v4l.org/oDuTv>