Bug #53934 [Com]: The negative PHP_INT_MAX is incorrectly converted to float

Edit report at https://bugs.php.net/bug.php?id=53934&edit=1 ID: 53934 Comment by: spam2 at rhsoft dot net Reported by: eriksen dot costa at infranology dot com dot br Summary: The negative PHP_INT_MAX is incorrectly converted to float Status: Not a bug Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.5 Block user comment: N Private report: N New Comment: this is unaccepatble because "$class->property = -9223372036854775808" while even don't know that the value *is* PHP_INT_MIN must not end as float in a strict-typed application php > echo PHP_INT_MIN; -9223372036854775808 php > echo is_int(PHP_INT_MIN); 1 php > $x = -9223372036854775808; php > echo is_float($x); 1 Previous Comments: ------------------------------------------------------------------------ [2018-05-29 12:30:50] spam2 at rhsoft dot net how the f**k is that not a bug and how does http://www.php.net/manual/ justify that gambling machine behavior? php > $x = 9223372036854775808; php > echo is_int($x); php > $x = (int)9223372036854775808; php > echo is_int($x); 1 ----- php > $x = 9223372036854775808; php > echo is_int($x); php > $x = (int)9223372036854775808; php > echo is_int($x); 1 ------------------------------------------------------------------------ [2018-05-29 12:20:16] ajf@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php ------------------------------------------------------------------------ [2018-05-29 12:18:49] spam2 at rhsoft dot net come on, explain me why the large number becomes a float when we all known from hundrets of bugrports that float values are making nothing than trouble swhen you touch or even echo them in doubt php > $x = 9223372036854775808; php > echo is_float($x); 1 php > $x = 922337203685477; php > echo is_float($x); php > echo is_int($x); 1 ------------------------------------------------------------------------ [2018-05-29 12:16:00] spam2 at rhsoft dot net hell, there are a ton of problems - when a constant named with INT on a x86_64 fails is_int() something is seriously broken - @cmb: as you can see with -100 the minus sign is not problem PHP_INT_MIN and PHP_INT_MAX a *both float* which is wrong - period php > $x = -100; php > echo is_int($x); 1 php > $x = 9223372036854775808; php > echo is_float($x); 1 php > echo is_int($x); php > php > echo PHP_INT_MAX; 9223372036854775807 php > echo PHP_INT_MIN; -9223372036854775808 php > $x = -9223372036854775808; php > echo is_int($x); php > $x = 9223372036854775808; php > echo is_int($x); php > echo is_int(1); 1 php > $x = 1000; php > echo is_int($x); 1 php > ------------------------------------------------------------------------ [2018-05-29 11:41:13] cmb@php.net In my opinion, this is not a bug, but rather a documentation issue. PHP (as many other languages, I believe) does not support signed literals, but rather only unsigned literals plus the identity and negation operators. If we would introduce the notion of signed integer literals, there would be a difference between -9223372036854775808 and 0-9223372036854775808 – that's even more confusing. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53934 -- Edit this bug report at https://bugs.php.net/bug.php?id=53934&edit=1