#30695 [Opn]: 0x80000000 treated as 0x7fffffff

From: Date: Wed, 10 Nov 2004 22:11:23 +0000
Subject: #30695 [Opn]: 0x80000000 treated as 0x7fffffff
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-68921@lists.php.net to get a copy of this message
ID: 30695 Updated by: derick@php.net Reported By: php_bug at cklowe dot com Status: Open Bug Type: Math related Operating System: Win32 PHP Version: 4CVS-2004-11-05 (stable) New Comment: THis is a change most likely caused by Joe's patches to it. I say we should revert it as it breaks too many scripts. Previous Comments: ------------------------------------------------------------------------ [2004-11-10 19:30:11] php_bug at cklowe dot com I see your point, and I'm happy that integers are unsigned. What worries me is that large hex initialisers (>= 0x80000000) are not doing their job. This is a change in behaviour. Python v 2.4 and above, uses Large Integers for 0x80000000 which seems acceptable. In previous versions it did the Right Thing and treated 0x80000000 as -214783648. Bitwise operations work as expected. PHP did the Right Thing in version 4.3.8. As of the current snapshot it no longer does the Right Thing. ------------------------------------------------------------------------ [2004-11-10 18:59:13] tony2001@php.net >This is *not* a signed/unsigned integer problem No, why? It is. And it can be clearly seen in this example: <? define ("BIG_NUM", 0x80000000); $big_var = 0x80000000; printf("%u, %u\n", BIG_NUM, $big_var); printf("%f, %f\n", BIG_NUM, $big_var); ?> Overflown integers are treated as floats and you cannot use bitwise operators on floats (as I understand you use them to check access privileges). ------------------------------------------------------------------------ [2004-11-10 18:37:48] php_bug at cklowe dot com This is a change in behaviour. In version 4.3.8 (for example) the expected result is displayed. In the snapshot of a week ago, the actual result was displayed. This is *not* a signed/unsigned integer problem (sorry if my description was unclear). It is an initialization from a numeric literal problem. Saturation to 0x7fffffff should not occur. If you like, 0x80000000 should be treated as -2147483648. Having (say) 0x80000000 treated as any ther value than 0x80000000 is surely wrong. Forgive me for reopening this bug, but I fear I must. ------------------------------------------------------------------------ [2004-11-10 18:16:01] tony2001@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 PHP does not support unsigned integers. ------------------------------------------------------------------------ [2004-11-05 18:35:57] php_bug at cklowe dot com Description: ------------ Large integers are being saturated to the maximum signed value (0x7fffffff) as opposed to being treated as the unsigned values. Panic! I had code that set the high bit in a Permissions variable when some condition was met. After changing PHP versions because of bug 25570, I found user reports of "Why have I got all these additional permissions?" and "I've now got Admin rights, OOoooh. What happens if I run this SQL query in the page I now have access to?". Reproduce code: --------------- define ("BIG_NUM", 0x80000000); $big_var = 0x80000000; echo sprintf("%08x, %08x", BIG_NUM, $big_var); Expected result: ---------------- 80000000,80000000 Actual result: -------------- 7fffffff, 7fffffff ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=30695&edit=1

« previous php.bugs (#68921) next »