Am 01.12.20 um 19:23 schrieb G. P. B.:
> So why having is_file()/is_dir() throw a warning for the past 8 years
> (since PHP 5.4) a non-issue? Because by that logic it shouldn't
> have been emitting warnings either.
> Would it have been fine if this would have been a TypeError as it was
> originally intended?
> Is a warning fine because null bytes indicate a potential attack as in no
> sane
> context should null bytes be passed around?
>
> I don't personally *care* that it throws a ValueError, but why is this
> issue only
> brought up *now* when it should have been shouting for 8 years and is
> either an
> indication of a bug or of something larger at play.
Keep cool, the code we are currently using is similar to this one:
if( @is_file( $data ) === false ) {
throw new \Aimeos\MW\Exception( 'Invalid file' );
}
We use the silence operator to suppress the warning so we can throw our
own exception in a clean way. Now, with support for PHP 8 it would be:
try
{
if( @is_file( $data ) === false ) {
throw new \Aimeos\MW\Exception( 'Invalid file' );
}
}
catch( \ValueException $e )
{
throw new \Aimeos\MW\Exception( $e->getMessage(), 0 , $e );
}
But it has two problems:
- It's much more code for the same thing
- The stack trace begins at the new exception, not the one at is_file()
We can't use the ValueException directly because this will lead to two
different exceptions depending on the used PHP version and our unittests
currently fails because of the different exceptions.
Norbert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
