Bug #70714 [Opn->Nab]: Type change when adding to PHP_INT_MAX

Edit report at https://bugs.php.net/bug.php?id=70714&edit=1 ID: 70714 Updated by: requinix@php.net Reported by: geggleto at gmail dot com Summary: Type change when adding to PHP_INT_MAX -Status: Open +Status: Not a bug Type: Bug Package: Variables related Operating System: Linux PHP Version: 7.0.0RC4 Block user comment: N Private report: N New Comment: http://php.net/manual/en/language.types.integer.php#language.types.integer.overflow > If PHP encounters a number beyond the bounds of the integer type, it will be > interpreted as a float instead. Also, an operation which results in a number > beyond the bounds of the integer type will return a float instead. Previous Comments: ------------------------------------------------------------------------ [2015-10-14 17:52:29] geggleto at gmail dot com Description: ------------ When adding to PHP_INT_MAX the PHP internals switch the type from INT to FLOAT. This should be documented. The real problem is when you attempt to cast it back to int. Reference: https://github.com/paragonie/random_compat/issues/50#issuecomment-148128683 Test script: --------------- <?php $min = PHP_INT_MAX + 1; var_dump($min); $newMin = (int)$min; var_dump($newMin); Expected result: ---------------- I expect that a Exception or Warning would be raised. E_WARNING | E_NOTICE would be acceptable, I would use E_WARNING I think that this code should register 2 warnings. 1) When you are overflowing the integer, and the engine is recasting to float. 2) When you are casting from Float to Int and the cast will lose data. Actual result: -------------- float(9.2233720368548E+18) int(-9223372036854775808) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=70714&edit=1