You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Timecop seems to be clobbering these type checks, resulting in no typechecking on calls made to overridden functions, as if strict_types wasn't enabled.
The following script, when run without timecop enabled, will fatally error "strtotime() expects parameter 1 to be string, null given" (as is correct). With timecop, the error is suppressed, causing execution to continue to show 'End!':
<?phpdeclare(strict_types=1);
strtotime(null); // fatal error without timecop, silent success with timecopecho"End!\n";
This resulted in fatal errors being thrown in our Production environment, which do not occur in our Testing environment, as the latter uses Timecop. While those erroneous nulls should be patched, it was pretty confusing to trace down the in-production-only error, and I suspect this is likely to happen to others as the intended usage of Timecop is to be run in testing only.
The text was updated successfully, but these errors were encountered:
Nebual
added a commit
to Nebual/php-timecop
that referenced
this issue
Jan 14, 2019
PHP 7.0 added
declare(strict_types=1);
, which enables strict type checking of all method calls made in a file with that declaration, including internal functions such asstrtotime()
. https://wiki.php.net/rfc/scalar_type_hints_v5#strict_types_declare_directiveTimecop seems to be clobbering these type checks, resulting in no typechecking on calls made to overridden functions, as if strict_types wasn't enabled.
The following script, when run without timecop enabled, will fatally error "strtotime() expects parameter 1 to be string, null given" (as is correct). With timecop, the error is suppressed, causing execution to continue to show 'End!':
This resulted in fatal errors being thrown in our Production environment, which do not occur in our Testing environment, as the latter uses Timecop. While those erroneous nulls should be patched, it was pretty confusing to trace down the in-production-only error, and I suspect this is likely to happen to others as the intended usage of Timecop is to be run in testing only.
The text was updated successfully, but these errors were encountered: