#44995 [Com]: bcpowmod() should not have scale parameter (only 0 is supported)
ID: 44995
Comment by: terrafrost at gmail dot com
Reported By: nat at fishtrap dot co dot uk
Status: Analyzed
Bug Type: BC math related
Operating System: *
PHP Version: 5.*, 6 (2009-09-20)
New Comment:
Related to this...
That outputs the following:
17334
1140.8
It seems to me that the output of the above ought to either be this:
Warning: bcpowmod() expects at most 3 parameters, 4 given
...or this:
17334
17334.0
Previous Comments:
[2009-09-20 14:43:23] sjo...@php.net
John Hasler said:
The example in #44995 is wrong. "^" has higher precedence than "%" so
"4^4%3" means "(4^4)%3" or "256%3", not "4^(4%3). The latter gives a
runtime error in bc with scale=1, as it should as fractional exponents
are not supported.
>From number.c:
/* Raise BASE to the EXPO power, reduced modulo MOD. The result is
placed in RESULT. If a EXPO is not an integer,
only the integer part is used. */
...
...
...
/* Check the base for scale digits. */
if (base->n_scale != 0)
bc_rt_warn ("non-zero scale in base");
/* Check the exponent for scale digits. */
if (exponent->n_scale != 0)
{
bc_rt_warn ("non-zero scale in exponent");
bc_divide (exponent, _one_, &exponent, 0); /*truncate */
}
/* Check the modulus for scale digits. */
if (mod->n_scale != 0)
bc_rt_warn ("non-zero scale in modulus");
...
...
...
As you can see, non-zero scale is not supported. Thus the bug is in
bcpowmod(). It should not accept a scale, and the documentation
should
say so.
[2009-09-19 18:22:41] sjo...@php.net
This seems to be a bug in the bc library. I asked jhasler to look into
it.
[2008-05-14 16:26:56] nat at fishtrap dot co dot uk
Description:
When using the 4th optional parameter of bcpowmod. The answer is always
zero and does not match the answer using bc directly.
This is also true if you set the scale using bcscale(1).
In short if the scale is non zero I can't find any way of getting
anything apart from zero as the result.
Reproduce code:
---
echo bcpowmod("4", "4", "3", 1 ) ,PHP_EOL;
Expected result:
0.1
in bc
scale =1;
4^4%3;
.1
Actual result:
--
0.0
--
Edit this bug report at http://bugs.php.net/?id=44995&edit=1
#49715 [Bgs]: float to string conversions
ID: 49715
User updated by: terrafrost at gmail dot com
Reported By: terrafrost at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.11
New Comment:
Hmmm - I didn't realize the output would be machine dependent nor did I
know that Perl behaved similarly. Given this, I guess I agree with the
closure. If there's a problem, I guess it's with the host system and
not with PHP, itself.
Previous Comments:
[2009-10-01 18:12:23] ras...@php.net
My main question here is what exactly you think we can do about this?
We aren't artificially limiting the precision. We work with the OS we
are on. If you run your script on a 64-bit OS (Linux in my case) the
output is:
4503599627370496
4503599627370496
equal
not equal
Which is what you are expecting, correct?
Run it on a 32-bit OS (Mac OSX 10.5 in my case) and the output is:
4.5035996273705E+15
4.5035996273705E+15
equal
not equal
This, of course, is not unique to PHP. Try this Perl script on the
same 32-bit box:
print 2**52;
print "\n";
print 4503599627370496;
print "\n";
if (2**52 == 4503599627370496) { print 'equal'; } else { print 'not
equal'; }
print "\n";
if (2**52 == 4503599627370500) { print 'equal'; } else { print 'not
equal'; }
And the output is:
4.5035996273705e+15
4.5035996273705e+15
equal
not equal
So, you will be filing the same bug against Perl, I guess?
And just for completeness, that Perl script on my 64-bit Linux box
outputs:
4.5035996273705e+15
4503599627370496
equal
not equal
So, Perl is actually more broken than PHP here.
--------------------
[2009-10-01 16:58:03] terrafrost at gmail dot com
Maybe you should reread my bug report instead of giving knee jerk
reactions. Do you even know what a mantissa is? If you hit Ctrl + F5
on the webpage you cited, you'll come across that term.
Anyway, if the mantissa has 53 bits of precision, why is PHP only
showing 48 bits? Oh - but because the precision is "limited", I guess
that's not really a problem, is it?
You know what else has "limited precision"? 32-bit integers. Even
though those support numbers from −2,147,483,648 to 2,147,483,647,
I guess it's not really a problem if PHP's echo statement was only
capable of showing numbers ranging from, say, -128 to 127. After all,
why waste an opportunity to arbitrarily and artificially reduce
precision for no real reason what-so-ever! And if anyone complains,
just remind them that they, too, have a "limited precision"!
[2009-10-01 16:14:13] j...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
[2009-09-29 20:52:56] terrafrost at gmail dot com
Description:
Displaying a float in base-10 when fractional values are involved is
difficult, as per <http://php.net/float>. Even if fractional values
aren't involved, displaying the float might still be problematic, if the
number you're trying to display is to big to be stored in the mantissa
of a floating point number.
Problem is, floating point numbers aren't always displayed correctly,
even if the mantissa can hold the number in question. For example, if
you have a double precision floating point number, your mantissa has 53
bits. The following corroborates this:
That, for me, displays 53.
The problem occurs with anything utilizing 48 or more mantissa bits:
Reproduce code:
---
Expected result:
4503599627370496
4503599627370496
equal
not equal
Actual result:
--
4503599627370500
4503599627370500
equal
not equal
--
Edit this bug report at http://bugs.php.net/?id=49715&edit=1
#49715 [Bgs]: float to string conversions
ID: 49715 User updated by: terrafrost at gmail dot com Reported By: terrafrost at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.2.11 New Comment: Maybe you should reread my bug report instead of giving knee jerk reactions. Do you even know what a mantissa is? If you hit Ctrl + F5 on the webpage you cited, you'll come across that term. Anyway, if the mantissa has 53 bits of precision, why is PHP only showing 48 bits? Oh - but because the precision is "limited", I guess that's not really a problem, is it? You know what else has "limited precision"? 32-bit integers. Even though those support numbers from −2,147,483,648 to 2,147,483,647, I guess it's not really a problem if PHP's echo statement was only capable of showing numbers ranging from, say, -128 to 127. After all, why waste an opportunity to arbitrarily and artificially reduce precision for no real reason what-so-ever! And if anyone complains, just remind them that they, too, have a "limited precision"! Previous Comments: [2009-10-01 16:14:13] j...@php.net Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. ---------------- [2009-09-29 20:52:56] terrafrost at gmail dot com Description: Displaying a float in base-10 when fractional values are involved is difficult, as per <http://php.net/float>. Even if fractional values aren't involved, displaying the float might still be problematic, if the number you're trying to display is to big to be stored in the mantissa of a floating point number. Problem is, floating point numbers aren't always displayed correctly, even if the mantissa can hold the number in question. For example, if you have a double precision floating point number, your mantissa has 53 bits. The following corroborates this: That, for me, displays 53. The problem occurs with anything utilizing 48 or more mantissa bits: Reproduce code: --- Expected result: 4503599627370496 4503599627370496 equal not equal Actual result: -- 4503599627370500 4503599627370500 equal not equal -- Edit this bug report at http://bugs.php.net/?id=49715&edit=1
#49715 [NEW]: float to string conversions
From: terrafrost at gmail dot com Operating system: Windows XP PHP version: 5.2.11 PHP Bug Type: Scripting Engine problem Bug description: float to string conversions Description: Displaying a float in base-10 when fractional values are involved is difficult, as per <http://php.net/float>. Even if fractional values aren't involved, displaying the float might still be problematic, if the number you're trying to display is to big to be stored in the mantissa of a floating point number. Problem is, floating point numbers aren't always displayed correctly, even if the mantissa can hold the number in question. For example, if you have a double precision floating point number, your mantissa has 53 bits. The following corroborates this: That, for me, displays 53. The problem occurs with anything utilizing 48 or more mantissa bits: Reproduce code: --- Expected result: 4503599627370496 4503599627370496 equal not equal Actual result: -- 4503599627370500 4503599627370500 equal not equal -- Edit bug report at http://bugs.php.net/?id=49715&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49715&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49715&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49715&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49715&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49715&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49715&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49715&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49715&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49715&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49715&r=support Expected behavior: http://bugs.php.net/fix.php?id=49715&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49715&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49715&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49715&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49715&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49715&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49715&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49715&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49715&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49715&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49715&r=mysqlcfg
#36524 [NEW]: Negative indexes in strings
From: terrafrost at gmail dot com
Operating system: any
PHP version: 4.4.2
PHP Bug Type: Feature/Change Request
Bug description: Negative indexes in strings
Description:
Currently, in PHP, if you want to reference the last character of a
string, you'd need to do something like $x{strlen($x)-1}. If using
substr, however, you can do substr($x,-1,1) or substr($x,strlen($x)-1,1).
In keeping with the former substr example, $x{-1} could be made to access
the last character of a string as well. Since, right now, using negative
numbers will result in a warning, it seems unlikely that any existing code
is going to be broken by such a change...
--
Edit bug report at http://bugs.php.net/?id=36524&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36524&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36524&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36524&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36524&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36524&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36524&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36524&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36524&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36524&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36524&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36524&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36524&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36524&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36524&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36524&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36524&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36524&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36524&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36524&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36524&r=mysqlcfg
#36493 [NEW]: Unable to determine maximum floating point b
From: terrafrost at gmail dot com Operating system: Linux PHP version: 4.4.2 PHP Bug Type: Math related Bug description: Unable to determine maximum floating point b Description: I've ran into some difficulty attempting to figure out what the maximum size of the exponent in floats is. Reproduce code: --- ($y*=2); $bits++); echo $bits; ?> Expected result: Assuming php.net's statement about the 64-bit IEEE standard being the most common representation of float, I'd expect to get 1024 as the result. Actual result: -- On Windows, I do indeed get the correct result. On Linux, all I get are timeout errors. I've tried it with both PHP4 and PHP5 and get the same results for each. -- Edit bug report at http://bugs.php.net/?id=36493&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36493&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36493&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36493&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36493&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36493&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36493&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36493&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36493&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36493&r=support Expected behavior:http://bugs.php.net/fix.php?id=36493&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36493&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36493&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36493&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36493&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36493&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36493&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36493&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36493&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36493&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36493&r=mysqlcfg
#33912 [Com]: Crash when trying to access registry using com
ID: 33912
Comment by: terrafrost at gmail dot com
Reported By: awsewell at catawba dot edu
Status: Assigned
Bug Type: COM related
Operating System: Windows XP
PHP Version: 5CVS-2005-07-29
Assigned To: wez
New Comment:
Doesn't seem to work on the latest beta of PHP5, but it works on
PHP4...
EnumKey(HKEY_LOCAL_MACHINE, $keyPath, &$keys);
$keys = $keys->value;
foreach($keys as $key){
print "$key\n";
}
?>
Previous Comments:
----
[2005-08-02 00:49:14] terrafrost at gmail dot com
EnumKey's first variable isn't supposed to be a string - it's supposed
to be an int. The number representing HKEY_LOCAL_MACHINE is
0x8002.
Check out the following link for more information:
http://msdn.microsoft.com/library/en-us/wmisdk/wmi/enumkey_method_in_class_stdregprov.asp
That said, even when "HKEY_LOCAL_MACHINE" is replaced with 0x8002
in awsewell's code, the code still doesn't work as it should. The
problem would seem to be due to arrays not being passed by reference.
I say that because in vBScript, they do seem to be (just check out the
examples in the link I provided).
[2005-07-28 23:41:02] awsewell at catawba dot edu
I tried the latest version via the link provided and get the same
results.
[2005-07-28 23:34:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-28 23:30:55] awsewell at catawba dot edu
Description:
When trying to use php 5.04 to access the registry with the code below
PHP crashes.
Reproduce code:
---
EnumKey("HKEY_LOCAL_MACHINE", $keyPath, $keys);
foreach($keys as $key){
print $key;
}
unset($wshShell);
?>
Expected result:
I execpt to see the list of subkeys from the registry.
Actual result:
--
PHP crashes with only "CLI has encountered a problem and needs to
close. We are sorry for the inconvenience."
--
Edit this bug report at http://bugs.php.net/?id=33912&edit=1
#33912 [Com]: Crash when trying to access registry using com
ID: 33912
Comment by: terrafrost at gmail dot com
Reported By: awsewell at catawba dot edu
Status: Assigned
Bug Type: COM related
Operating System: Windows XP
PHP Version: 5CVS-2005-07-29
Assigned To: wez
New Comment:
EnumKey's first variable isn't supposed to be a string - it's supposed
to be an int. The number representing HKEY_LOCAL_MACHINE is
0x8002.
Check out the following link for more information:
http://msdn.microsoft.com/library/en-us/wmisdk/wmi/enumkey_method_in_class_stdregprov.asp
That said, even when "HKEY_LOCAL_MACHINE" is replaced with 0x8002
in awsewell's code, the code still doesn't work as it should. The
problem would seem to be due to arrays not being passed by reference.
I say that because in vBScript, they do seem to be (just check out the
examples in the link I provided).
Previous Comments:
[2005-07-28 23:41:02] awsewell at catawba dot edu
I tried the latest version via the link provided and get the same
results.
[2005-07-28 23:34:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-28 23:30:55] awsewell at catawba dot edu
Description:
When trying to use php 5.04 to access the registry with the code below
PHP crashes.
Reproduce code:
---
EnumKey("HKEY_LOCAL_MACHINE", $keyPath, $keys);
foreach($keys as $key){
print $key;
}
unset($wshShell);
?>
Expected result:
I execpt to see the list of subkeys from the registry.
Actual result:
--
PHP crashes with only "CLI has encountered a problem and needs to
close. We are sorry for the inconvenience."
--
Edit this bug report at http://bugs.php.net/?id=33912&edit=1
#30463 [Opn]: popen crashes webservers
ID: 30463 User updated by: terrafrost at gmail dot com Reported By: terrafrost at gmail dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 4.3.9 New Comment: The problem also seems to effect proc_open... Previous Comments: [2004-10-17 08:17:53] terrafrost at gmail dot com Description: When run from a webserver, the following two scripts cause the webserver to crash. In contrast, no such problem occurs when these scripts are run from the command line. Reproduce code: --- ptest.php: and hello.php: Expected result: I expect the following to be displayed: hello, world! hello, world! Actual result: -- When run from the command line, the expected result is the actual result. However, when run from a webserver (I tried Apache 2.0.52 and Abyss Web Server 1.2.3.0) they create a bunch of php and cmd processes (more than it should) and none of them are terminated. In the case of Apache, processes are no longer created after the first 10 or so are. Afterwards, trying to view php scripts, with Apache, causes an Internal Server Error. In the case of Abyss, processes are no longer created when the system has run out of ram. -- Edit this bug report at http://bugs.php.net/?id=30463&edit=1
#30463 [NEW]: popen crashes webservers
From: terrafrost at gmail dot com Operating system: Windows XP PHP version: 4.3.9 PHP Bug Type: Reproducible crash Bug description: popen crashes webservers Description: When run from a webserver, the following two scripts cause the webserver to crash. In contrast, no such problem occurs when these scripts are run from the command line. Reproduce code: --- ptest.php: and hello.php: Expected result: I expect the following to be displayed: hello, world! hello, world! Actual result: -- When run from the command line, the expected result is the actual result. However, when run from a webserver (I tried Apache 2.0.52 and Abyss Web Server 1.2.3.0) they create a bunch of php and cmd processes (more than it should) and none of them are terminated. In the case of Apache, processes are no longer created after the first 10 or so are. Afterwards, trying to view php scripts, with Apache, causes an Internal Server Error. In the case of Abyss, processes are no longer created when the system has run out of ram. -- Edit bug report at http://bugs.php.net/?id=30463&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30463&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30463&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30463&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30463&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30463&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30463&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30463&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30463&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30463&r=support Expected behavior: http://bugs.php.net/fix.php?id=30463&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30463&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30463&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30463&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30463&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30463&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30463&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30463&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30463&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30463&r=mysqlcfg
