[PHP-DEV] Stream Error Degradation: They're now missing what can't be opened

Mailing Lists php.internals
1

Hi,

Since the last few days, some of my tests for Xdebug started failing
with latest master: https://xdebug.org/ci?r=2026-07-24-03-30-01@master

Through commit stream: remove path parameter in stream error functions (#22792) · php/php-src@34c686a · GitHub, the
filenames and dirnames are removed as argument, from the warnings/errors
to include, require, etc — as a result of
PHP: rfc:display_error_function_args

While that is perhaps a noble goal, not showing which file couldn't be
included in many situations, such as:

Warning: include(): Failed to open stream: No such file or directory in %sinclude_path.php on line %d
Warning: require_once(): Failed to open stream: No such file or directory in /tmp/ptester-1001/thread/12/master/tmp-xdebug/tests/base/bug02307-002.php on line 9

And also in many other functions:

Warning: bzopen(): Failed to open stream: No such file or directory in %s on line %d
Warning: dba_open(): Failed to open stream: No such file or directory in %s on line %d
Warning: finfo_open(): Failed to open stream: No such file or directory in %s on line %d
Warning: imagecreatefrompng(): Failed to open stream: No such file or directory in %s on line %d

Doesn't seem to me like an enhanced for users, which would likely very
much to know which file is being included/required/bzopen'ed, etc.

I think we ought to fix this situations by included the file/directory
that can't be opened in the error messages themselves. Or if that is not
possible, then I would probably suggest to revert this change (even
though it was RFC'ed) until there is a possibility for not degrading the
usefulness of our error messages.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud
Author of Xdebug. Like it? Consider supporting me: Xdebug: Support
mastodon: @derickr@phpc.social @xdebug@phpc.social

2

On Fri, 24 Jul 2026 at 11:51, Derick Rethans <derick@php.net> wrote:

Hi,

Since the last few days, some of my tests for Xdebug started failing
with latest master: https://xdebug.org/ci?r=2026-07-24-03-30-01@master

Through commit stream: remove path parameter in stream error functions (#22792) · php/php-src@34c686a · GitHub, the
filenames and dirnames are removed as argument, from the warnings/errors
to include, require, etc — as a result of
PHP: rfc:display_error_function_args

While that is perhaps a noble goal, not showing which file couldn't be
included in many situations, such as:

Warning: include(): Failed to open stream: No such file or directory in %sinclude_path.php on line %d
Warning: require_once(): Failed to open stream: No such file or directory in /tmp/ptester-1001/thread/12/master/tmp-xdebug/tests/base/bug02307-002.php on line 9

And also in many other functions:

Warning: bzopen(): Failed to open stream: No such file or directory in %s on line %d
Warning: dba_open(): Failed to open stream: No such file or directory in %s on line %d
Warning: finfo_open(): Failed to open stream: No such file or directory in %s on line %d
Warning: imagecreatefrompng(): Failed to open stream: No such file or directory in %s on line %d

Doesn't seem to me like an enhanced for users, which would likely very
much to know which file is being included/required/bzopen'ed, etc.

I think we ought to fix this situations by included the file/directory
that can't be opened in the error messages themselves. Or if that is not
possible, then I would probably suggest to revert this change (even
though it was RFC'ed) until there is a possibility for not degrading the
usefulness of our error messages.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud
Author of Xdebug. Like it? Consider supporting me: Xdebug: Support
mastodon: @derickr@phpc.social @xdebug@phpc.social

I think it's better the way it is now. The file path could leak
sensitive information, and having the option to control when it is
included in the error message is a good idea. However, the path is
already included in some error messages, so if we want to align the
behaviour that way, we can include the path in all stream error
messages. But I am against reverting the change from the commit.

FWIW, I always hated the stream warnings. In many situations, they
duplicate the error from the main operation, and they don't provide
meaningful information. For example, include already throws a warning
with the name of the file being included. If the open_basedir is in
effect, you will actually get 3 warnings for a single failure. Streams
shouldn't be raising their own warnings and instead return an error
code to the caller so that the caller can raise an appropriate
message.