ID: 30695
Updated by: [EMAIL PROTECTED]
Reported By: php_bug at cklowe dot com
-Status: Open
+Status: Assigned
Bug Type: Math related
Operating System: Win32
PHP Version: 4CVS-2004-11-05 (stable)
-Assigned To:
+Assigned To: jorton
New Comment:
gcc bugfix seems to be creating more trouble that its worth. please
revert it before we release 4.3.10.
Previous Comments:
------------------------------------------------------------------------
[2004-11-14 23:51:31] php_bug at cklowe dot com
Yes, given the implications I believe a reversion would be wise.
------------------------------------------------------------------------
[2004-11-10 23:11:20] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[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] [EMAIL PROTECTED]
>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.
------------------------------------------------------------------------
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
http://bugs.php.net/30695
--
Edit this bug report at http://bugs.php.net/?id=30695&edit=1
