On 03.12.2020 at 11:20, Claude Pache wrote:
> `stats()` and friends invoked with empty string or null as argument, return
> `false` (indicating failure), but do not emit the Warning that is expected on
> failure. See: https://3v4l.org/jXC2N <https://3v4l.org/jXC2N>
>
> That discrepancy between the two ways of indicating failure is problematic.
> Indeed, whenever I use one of those functions without prefixing it by @, I
> expect that it will either return a value of expected type (`array` in case
> of `stats()`), or run the panic procedure of my error handler.
>
> I propose to ensure that those functions always emit a Warning in each and
> every situation they return false/null (provided, of course, that those
> functions are not supposed to return `false/null` in absence of failure, and
> that their purpose is not to check failure condition as in `file_exists()`).
Returning false without raising a warning has been introduced[1] to fix
bug #21410[2]. The problem back then was that without that early
return, on Windows the empty string gave erroneous stat() results, and
filetype("") returned "dir". This is no longer the case at least as of
PHP 7.3.0 (I didn't test older versions); instead after reverting
560e33968d I now get:
Warning: stat(): stat failed for in %s on line %d
bool(false)
So, yes, I think we should revert that commit.
[1] <https://github.com/php/php-src/commit/560e33968d>
[2] <https://bugs.php.net/21410>
Regards,
Christoph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
