Hi!
First, assuming that a null byte in a file name *is* an error condition, is the PHP 8 behavior better than in PHP 7? I think the answer to this one is very clearly "yes". The above code snippet and the subtle way in which it
For me as a user that would be a very clear "no". Now if I have any usage of these functions in my existing code, I have to go and replace them with safe wrapper to ensure it doesn't bail out in random places. It may be the same for functions like fopen() where you have to error-check anyway, but for functions like is_* it's strictly worse. In fact, I am struggling to find a scenario where it's better for me as a user from the code robustness PoV - it's either the same or worse.
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.
Second, should a null byte in a file name be an error condition in the first place? This is a point I'm not sure about. It would certainly be possible to treat paths containing null bytes as non-existing paths, and abstract away the fact that paths cannot contain null bytes, and that this is a common attack vector. I'd personally lean towards not considering null bytes an error condition.
This is a kind of philosophical question, like whether or not trying to open a file that doesn't exist is an "error condition". Throw-happy languages like Java think it is, other languages like C or PHP treat it in different way. But I think in any case what we've got in 8 with is_* is not an improvement.
-- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
