file_exists() throws exception when a NULL character exists in string

[calnetwebmaster]

In FsPathPlugin, in the parse() method, when a null byte exists in the passed in parameter, file_exists throws an exception. If you replace NULL characters the exception is prevented

[jnvsor]

What php version are you on to get this? 8.2 and the git master both have no problem with strings with nuls in them

According to the TypeError docs:

The argument type being passed to a function does not match its corresponding declared parameter type.

But there's no type hint for "Path" strings nor is that actually used by PHP

Are you overriding file_exists with something?

[calnetwebmaster]

The server is running php 7.4 and working inside the Codeigniter MVC framework. I'll dig around and see if the framework overrides it, but it seems to be using the root namespace.

[jnvsor]

Apparently file_exists had an undocumented warning that was fixed in 8.0.1

Prior to 8.0 error suppression normally prevents any warning from being emitted but you can use set_error_handler to turn it into an exception while ignoring the error suppression operator.

Now the parser has an exception catch around plugins to prevent plugins from crashing execution, but this only handles Exception and since you have a TypeError it gets through the catch.

Unfortunately all this probably has nothing to do with this error since codeigniter turns errors into ErrorException not TypeError and should respect the error suppression operator too...

I wasn't able to find anything related to TypeError in a fresh CI4 install so I'm stumped as to where it came from.

Ultimately changing it to catch throwables instead of exceptions might fix this issue, but then kint produces a warning and (Especially in debug mode) your framework might decide to kill everything then anyway.

So long story short I still don't know what causes this specific bug a year later, but we know it doesn't happen on PHP 8 at least...

It may be some third party library is messing with the error handlers, if you're still interested in looking at this bug try set_error_handler($h = set_error_handler('var_dump')); d($h); to see what the current error handler is. Otherwise since no-one else has reported similar errors I'll have to assume it's a quirk of your codebase

[jnvsor]

Well I'm an idiot. The undocumented error becomes a TypeError because of declare(strict_types=1); - which is why when I tested it in a naive script it didn't do anything.

Apparently strict types ignores error suppression and I didn't have a test case for this. I'll be going through and checking this with all suppressed errors now