On Fri, 24 Jul 2026 at 11:51, Derick Rethans <[email protected]> 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 https://github.com/php/php-src/commit/34c686a5b4ef, the > filenames and dirnames are removed as argument, from the warnings/errors > to include, require, etc — as a result of > https://wiki.php.net/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: https://xdebug.org/support > mastodon: @[email protected] @[email protected]
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.
