[PHP-BUG] Bug #51547 [NEW]: Type casting from int to int after log changes value
From: Operating system: PHP version: 5.2.13 Package: *Math Functions Bug Type: Bug Bug description:Type casting from int to int after log changes value Description: When performing a log(), and immediately type casting afterwards, the value changes. Test script: --- ?php $val = 1000; echo log($val, 10) .' == '. (int) log($val, 10); ? Expected result: 3 == 3 Actual result: -- 3 == 2 -- Edit bug report at http://bugs.php.net/bug.php?id=51547edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51547r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51547r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51547r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51547r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51547r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51547r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51547r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51547r=needscript Try newer version: http://bugs.php.net/fix.php?id=51547r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51547r=support Expected behavior: http://bugs.php.net/fix.php?id=51547r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51547r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51547r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51547r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51547r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51547r=dst IIS Stability: http://bugs.php.net/fix.php?id=51547r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51547r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51547r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51547r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51547r=mysqlcfg
Bug #51547 [Opn]: Type casting from int to int after log changes value
Edit report at http://bugs.php.net/bug.php?id=51547edit=1 ID: 51547 User updated by: acollins at liv dot ac dot uk Reported by: acollins at liv dot ac dot uk Summary: Type casting from int to int after log changes value Status: Open Type:Bug Package: *Math Functions PHP Version: 5.2.13 New Comment: Note: I assume this is because log() returns a floating point value. I.e. it's a precision issue? Previous Comments: [2010-04-13 11:03:32] acollins at liv dot ac dot uk Description: When performing a log(), and immediately type casting afterwards, the value changes. Test script: --- ?php $val = 1000; echo log($val, 10) .' == '. (int) log($val, 10); ? Expected result: 3 == 3 Actual result: -- 3 == 2 -- Edit this bug report at http://bugs.php.net/bug.php?id=51547edit=1
Bug #51547 [Opn-Bgs]: Type casting from int to int after log changes value
Edit report at http://bugs.php.net/bug.php?id=51547edit=1 ID: 51547 Updated by: degeb...@php.net Reported by: acollins at liv dot ac dot uk Summary: Type casting from int to int after log changes value -Status: Open +Status: Bogus Type:Bug Package: *Math Functions PHP Version: 5.2.13 New Comment: 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. Try having a look at this: echo serialize(log(1000, 10)); When you cast to int you just truncate the fractional part. Previous Comments: [2010-04-13 11:04:47] acollins at liv dot ac dot uk Note: I assume this is because log() returns a floating point value. I.e. it's a precision issue? [2010-04-13 11:03:32] acollins at liv dot ac dot uk Description: When performing a log(), and immediately type casting afterwards, the value changes. Test script: --- ?php $val = 1000; echo log($val, 10) .' == '. (int) log($val, 10); ? Expected result: 3 == 3 Actual result: -- 3 == 2 -- Edit this bug report at http://bugs.php.net/bug.php?id=51547edit=1
Bug #51547 [Bgs]: Type casting from int to int after log changes value
Edit report at http://bugs.php.net/bug.php?id=51547edit=1 ID: 51547 Updated by: ahar...@php.net Reported by: acollins at liv dot ac dot uk Summary: Type casting from int to int after log changes value Status: Bogus Type:Bug Package: *Math Functions PHP Version: 5.2.13 New Comment: Exactly right: the first value is being rendered as 3 because of the fact that PHP limits the significant digits shown when converting a float to a string. If you look at the value of serialize(log(1000, 10)), you'll end up with something like the following: d:2.999555910790149937383830547332763671875; Which demonstrates that the internal representation is slightly less than 3. The explicit conversion to an integer causes the value to be rounded down, hence why you get 2. Previous Comments: [2010-04-13 11:24:06] degeb...@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. Try having a look at this: echo serialize(log(1000, 10)); When you cast to int you just truncate the fractional part. [2010-04-13 11:04:47] acollins at liv dot ac dot uk Note: I assume this is because log() returns a floating point value. I.e. it's a precision issue? [2010-04-13 11:03:32] acollins at liv dot ac dot uk Description: When performing a log(), and immediately type casting afterwards, the value changes. Test script: --- ?php $val = 1000; echo log($val, 10) .' == '. (int) log($val, 10); ? Expected result: 3 == 3 Actual result: -- 3 == 2 -- Edit this bug report at http://bugs.php.net/bug.php?id=51547edit=1
[PHP-BUG] Bug #51548 [NEW]: setting the php_auth_user using login form
From: Operating system: windows xpsp2 PHP version: 5.2.13 Package: PHP options/info functions Bug Type: Bug Bug description:setting the php_auth_user using login form Description: for auth-login, i don't like to have pop-up box to enter the username/password. i like to enter the username/password in login-form. Test script: --- ? $username = usa; $password = newyork; if(($_POST['PHP_AUTH_USER'] == $username) ($_POST['PHP_AUTH_PW'] == $password)) { echo apache_setenv(PHP_AUTH_USER,$_POST['PHP_AUTH_USER']); echo apache_setenv(PHP_AUTH_PW,$_POST['PHP_AUTH_PW']); echo putenv(PHP_AUTH_USER =$_POST['PHP_AUTH_USER']); echo putenv(PHP_AUTH_PW = $_POST['PHP_AUTH_PW']); } ? form method=post pUsername : input type=textbox name=PHP_AUTH_USER id=PHP_AUTH_USER /br / pPassword : input type=password name=PHP_AUTH_PW id=PHP_AUTH_PW /br / p input type=submit name=submit / /form Expected result: by using the phpinfo(), we need to see the _SERVER['PHP_AUTH_USER'] = usa. Actual result: -- by using the phpinfo(), '_SERVER['PHP_AUTH_USER'] ' is totally missed.. -- Edit bug report at http://bugs.php.net/bug.php?id=51548edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51548r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51548r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51548r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51548r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51548r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51548r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51548r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51548r=needscript Try newer version: http://bugs.php.net/fix.php?id=51548r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51548r=support Expected behavior: http://bugs.php.net/fix.php?id=51548r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51548r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51548r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51548r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51548r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51548r=dst IIS Stability: http://bugs.php.net/fix.php?id=51548r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51548r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51548r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51548r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51548r=mysqlcfg
Bug #51548 [Opn-Bgs]: setting the php_auth_user using login form
Edit report at http://bugs.php.net/bug.php?id=51548edit=1 ID: 51548 Updated by: degeb...@php.net Reported by: ram at wiredhat dot com Summary: setting the php_auth_user using login form -Status: Open +Status: Bogus Type: Bug Package: PHP options/info functions Operating System: windows xpsp2 PHP Version: 5.2.13 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2010-04-13 12:27:42] ram at wiredhat dot com Description: for auth-login, i don't like to have pop-up box to enter the username/password. i like to enter the username/password in login-form. Test script: --- ? $username = usa; $password = newyork; if(($_POST['PHP_AUTH_USER'] == $username) ($_POST['PHP_AUTH_PW'] == $password)) { echo apache_setenv(PHP_AUTH_USER,$_POST['PHP_AUTH_USER']); echo apache_setenv(PHP_AUTH_PW,$_POST['PHP_AUTH_PW']); echo putenv(PHP_AUTH_USER =$_POST['PHP_AUTH_USER']); echo putenv(PHP_AUTH_PW = $_POST['PHP_AUTH_PW']); } ? form method=post pUsername : input type=textbox name=PHP_AUTH_USER id=PHP_AUTH_USER /br / pPassword : input type=password name=PHP_AUTH_PW id=PHP_AUTH_PW /br / p input type=submit name=submit / /form Expected result: by using the phpinfo(), we need to see the _SERVER['PHP_AUTH_USER'] = usa. Actual result: -- by using the phpinfo(), '_SERVER['PHP_AUTH_USER'] ' is totally missed.. -- Edit this bug report at http://bugs.php.net/bug.php?id=51548edit=1
Bug #45176 [Com]: Create image from ttf file failed
Edit report at http://bugs.php.net/bug.php?id=45176edit=1 ID: 45176 Comment by: sridevigara at gmail dot com Reported by: heyond at yahoo dot com dot cn Summary: Create image from ttf file failed Status: No Feedback Type: Bug Package: GD related Operating System: windows 2003 PHP Version: 5.2.6 Assigned To: pajoye New Comment: Hi i am trying to create a image using hindi mangal (unicode) font text but i am facing a problem that matras are coming properly .Can anyone help me Previous Comments: [2009-03-10 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-03-02 15:49:40] paj...@php.net I need: - a small script to reproduce what you are doing - All fonts files you use with the script Without that, I can't help you to solve this problem, if there is any. [2008-12-16 10:08:02] patrick dot landolt at artack dot ch I also have the same problem with GD on PHP V5.2.6 installed. My font is a chinese one. [2008-06-05 06:45:11] heyond at yahoo dot com dot cn The completed script is: ?php define('BG1', 'DDD4BB'); header(Content-type: image/jpeg); $word = 'abc';//$word = 'ºº×Ö' $wordnum = 6; $word = iconv('GBK', 'UTF-8', $word); //$fontfile = './data/fonts/1.ttf';//http://www.guomo.com/data/fonts/1.ttf This file '1.ttf' is normal $fontfile = './data/fonts/174.ttf';//http://www.guomo.com/data/fonts/174.ttf This file '174.ttf' is abnormal $width = 30 $height = 40; $fontsize = 20; $x = 0; $y = $fontsize + 10; $im = imagecreate($wordnum * $width, $height); $bgcolor = imagecolorallocate($im, hexdec(substr(BG1, 0, 2)), hexdec(substr(BG1, 2, 2)), hexdec(substr(BG1, 4, 2))); $fgcolor = imagecolorallocate($im, 0, 0, 0); imagefill($im, 0, 0, $bgcolor); imagettftext($im, $fontsize, 0, $x, $y, $fgcolor, $fontfile, $word); imagejpeg($im); imagedestroy($im); exit; ? [2008-06-05 06:38:14] heyond at yahoo dot com dot cn http://www.guomo.com/data/fonts/174.ttf 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/bug.php?id=45176 -- Edit this bug report at http://bugs.php.net/bug.php?id=45176edit=1
[PHP-BUG] Bug #51550 [NEW]: 'Open php' tag at end of file causes 'syntax error, unexpected $end'
From: Operating system: Debian Etch PHP version: 5.2.13 Package: Scripting Engine problem Bug Type: Bug Bug description:'Open php' tag at end of file causes 'syntax error, unexpected $end' Description: This probably is a known effect, but I will just open a bug so it can be documented as such: When you end a file with a PHP open tag '?php', and there is no character beyond the tag the parser chokes with an 'unexpected $end' parse error. Curiously, a short tag '?' (if enabled) used in such a way raises no error. This effect is of course also seen when you eval a string containing an PHP open tag at the end of the string. (from there I originally stumbled on this behaviour) In PHP 5.3 the code behaves as expected, so someone probably already spotted this one, or fixed the parser to be less nitty. Test script: --- ?php Expected result: Nothin Actual result: -- Parse error: syntax error, unexpected $end in test.php on line 1 -- Edit bug report at http://bugs.php.net/bug.php?id=51550edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51550r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51550r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51550r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51550r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51550r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51550r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51550r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51550r=needscript Try newer version: http://bugs.php.net/fix.php?id=51550r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51550r=support Expected behavior: http://bugs.php.net/fix.php?id=51550r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51550r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51550r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51550r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51550r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51550r=dst IIS Stability: http://bugs.php.net/fix.php?id=51550r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51550r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51550r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51550r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51550r=mysqlcfg
Bug #51298 [Com]: Error when loading php5apache2_2.dll
Edit report at http://bugs.php.net/bug.php?id=51298edit=1 ID: 51298 Comment by: kck at mail dot ru Reported by: trotsky_icepick at hotmail dot com Summary: Error when loading php5apache2_2.dll Status: Assigned Type: Bug Package: Apache2 related Operating System: Windows Vista SP2 PHP Version: 5.3.2 Assigned To: jmertic New Comment: reproducable Micrisof Windows Server 2003 servie pack 2 Faulting application php.exe, version 5.2.13.13, faulting module php5ts.dll, version 5.2.13.13, fault address 0x000f351c. Previous Comments: [2010-04-07 20:05:23] noxwizard at gmail dot com I can reproduce this on Windows 7 x64 using the zipped versions. Apache: httpd-2.2.15-win32-x86-ssl.zip (Apache Lounge) PHP: php-5.3.2-Win32-VC9-x86.zip (Thread Safe, php.net) No extensions enabled. Problem signature: Problem Event Name: APPCRASH Application Name: apache.exe Application Version: 2.2.15.0 Application Timestamp:4b916754 Fault Module Name:StackHash_0a9e Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Code: c005 Exception Offset: 004bd5c9 [2010-03-29 23:04:31] paj...@php.net As I said, please use the Zip version in the meantime. [2010-03-29 22:35:55] ficcionista at gmail dot com I'm receiving the same error. Here's what I could find out: Installed the following on a fresh Win XP SP3 machine: - httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi - Defaults - php-5.3.2-Win32-VC6-x86.msi - Defaults As soon as I tried to start apache i get this error: The request operation has failed: Error signature: szAppName : httpd.exe szAppVer : 2.2.15.0 szModName : php5ts.dll szModVer : 5.3.2.0 offset : 000e6d2c On the Windows event viewer i got this: Faulting application httpd.exe, version 2.2.15.0, faulting module php5ts.dll, version 5.3.2.0, fault address 0x000e6d2c. I've also tried disabling PHP's extensions and then turning them on one by one. Here's the only PHP config that allowed me to start apache (Crippled, but running): Enabled extensions: php_bz2.dll php_curl.dll php_gd2.dll php_gettext.dll php_mysql.dll php_mysqli.dll php_openssl.dll php_soap.dll Disabled extensions php_dba.dll php_fdf.dll php_sockets.dll php_tidy.dll php_xmlrpc.dll php_xsl.dll php_zip.dll php_exif.dll php_gmp.dll php_imap.dll php_ldap.dll php_mbstring.dll php_mcrypt.dll php_mhash.dll php_mime_magic.dll php_ming.dll php_pspell.dll php_shmop.dll php_snmp.dll [2010-03-28 12:20:46] paj...@php.net It seems to be only a problem when you use the MSI. It does not happen if you install PHP manually using the zip releases. It also works if I completelly remove the PHP directory and run the MSI again. As it is critical that the MSI works smoothly, it is not like you don't have alternative right now to update to 5.3.2. The MSI maintainer is investigating the problem. [2010-03-28 06:39:11] jeftyneg at yahoo dot com Any update of this critical issue? I think thorough testing was not performed against Apache 2.2.15 due to the fact that Apache 2.2.15 was released 2 days after PHP 5.3.2 was released. Maybe there's a compatibility issue between Apache 2.2.15 and PHP 5.3.2. I personally considered this as a critical bug because this is a blocking issue. One can't proceed with testing the PHP scripts because installation can cause Apache 2.2.15 to crash. 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/bug.php?id=51298 -- Edit this bug report at http://bugs.php.net/bug.php?id=51298edit=1
Bug #51298 [Asn]: Error when loading php5apache2_2.dll
Edit report at http://bugs.php.net/bug.php?id=51298edit=1 ID: 51298 Updated by: jmer...@php.net Reported by: trotsky_icepick at hotmail dot com Summary: Error when loading php5apache2_2.dll Status: Assigned Type: Bug Package: Apache2 related Operating System: Windows Vista SP2 PHP Version: 5.3.2 -Assigned To: jmertic +Assigned To: pajoye New Comment: Sounds like this issue is in both packages, but sporadic to reproduce. Could we have changed any compiler options between the builds? Previous Comments: [2010-04-13 15:53:50] kck at mail dot ru reproducable Micrisof Windows Server 2003 servie pack 2 Faulting application php.exe, version 5.2.13.13, faulting module php5ts.dll, version 5.2.13.13, fault address 0x000f351c. [2010-04-07 20:05:23] noxwizard at gmail dot com I can reproduce this on Windows 7 x64 using the zipped versions. Apache: httpd-2.2.15-win32-x86-ssl.zip (Apache Lounge) PHP: php-5.3.2-Win32-VC9-x86.zip (Thread Safe, php.net) No extensions enabled. Problem signature: Problem Event Name: APPCRASH Application Name: apache.exe Application Version: 2.2.15.0 Application Timestamp:4b916754 Fault Module Name:StackHash_0a9e Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Code: c005 Exception Offset: 004bd5c9 [2010-03-29 23:04:31] paj...@php.net As I said, please use the Zip version in the meantime. [2010-03-29 22:35:55] ficcionista at gmail dot com I'm receiving the same error. Here's what I could find out: Installed the following on a fresh Win XP SP3 machine: - httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi - Defaults - php-5.3.2-Win32-VC6-x86.msi - Defaults As soon as I tried to start apache i get this error: The request operation has failed: Error signature: szAppName : httpd.exe szAppVer : 2.2.15.0 szModName : php5ts.dll szModVer : 5.3.2.0 offset : 000e6d2c On the Windows event viewer i got this: Faulting application httpd.exe, version 2.2.15.0, faulting module php5ts.dll, version 5.3.2.0, fault address 0x000e6d2c. I've also tried disabling PHP's extensions and then turning them on one by one. Here's the only PHP config that allowed me to start apache (Crippled, but running): Enabled extensions: php_bz2.dll php_curl.dll php_gd2.dll php_gettext.dll php_mysql.dll php_mysqli.dll php_openssl.dll php_soap.dll Disabled extensions php_dba.dll php_fdf.dll php_sockets.dll php_tidy.dll php_xmlrpc.dll php_xsl.dll php_zip.dll php_exif.dll php_gmp.dll php_imap.dll php_ldap.dll php_mbstring.dll php_mcrypt.dll php_mhash.dll php_mime_magic.dll php_ming.dll php_pspell.dll php_shmop.dll php_snmp.dll [2010-03-28 12:20:46] paj...@php.net It seems to be only a problem when you use the MSI. It does not happen if you install PHP manually using the zip releases. It also works if I completelly remove the PHP directory and run the MSI again. As it is critical that the MSI works smoothly, it is not like you don't have alternative right now to update to 5.3.2. The MSI maintainer is investigating the problem. 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/bug.php?id=51298 -- Edit this bug report at http://bugs.php.net/bug.php?id=51298edit=1
Bug #51298 [Asn]: Error when loading php5apache2_2.dll
Edit report at http://bugs.php.net/bug.php?id=51298edit=1 ID: 51298 Updated by: paj...@php.net Reported by: trotsky_icepick at hotmail dot com Summary: Error when loading php5apache2_2.dll Status: Assigned Type: Bug Package: Apache2 related Operating System: Windows Vista SP2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: No, we did not change options. Can you manage to get it with the zip as well? I can't. Or maybe a back trace would be helpful. Previous Comments: [2010-04-13 16:03:38] jmer...@php.net Sounds like this issue is in both packages, but sporadic to reproduce. Could we have changed any compiler options between the builds? [2010-04-13 15:53:50] kck at mail dot ru reproducable Micrisof Windows Server 2003 servie pack 2 Faulting application php.exe, version 5.2.13.13, faulting module php5ts.dll, version 5.2.13.13, fault address 0x000f351c. [2010-04-07 20:05:23] noxwizard at gmail dot com I can reproduce this on Windows 7 x64 using the zipped versions. Apache: httpd-2.2.15-win32-x86-ssl.zip (Apache Lounge) PHP: php-5.3.2-Win32-VC9-x86.zip (Thread Safe, php.net) No extensions enabled. Problem signature: Problem Event Name: APPCRASH Application Name: apache.exe Application Version: 2.2.15.0 Application Timestamp:4b916754 Fault Module Name:StackHash_0a9e Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Code: c005 Exception Offset: 004bd5c9 [2010-03-29 23:04:31] paj...@php.net As I said, please use the Zip version in the meantime. [2010-03-29 22:35:55] ficcionista at gmail dot com I'm receiving the same error. Here's what I could find out: Installed the following on a fresh Win XP SP3 machine: - httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi - Defaults - php-5.3.2-Win32-VC6-x86.msi - Defaults As soon as I tried to start apache i get this error: The request operation has failed: Error signature: szAppName : httpd.exe szAppVer : 2.2.15.0 szModName : php5ts.dll szModVer : 5.3.2.0 offset : 000e6d2c On the Windows event viewer i got this: Faulting application httpd.exe, version 2.2.15.0, faulting module php5ts.dll, version 5.3.2.0, fault address 0x000e6d2c. I've also tried disabling PHP's extensions and then turning them on one by one. Here's the only PHP config that allowed me to start apache (Crippled, but running): Enabled extensions: php_bz2.dll php_curl.dll php_gd2.dll php_gettext.dll php_mysql.dll php_mysqli.dll php_openssl.dll php_soap.dll Disabled extensions php_dba.dll php_fdf.dll php_sockets.dll php_tidy.dll php_xmlrpc.dll php_xsl.dll php_zip.dll php_exif.dll php_gmp.dll php_imap.dll php_ldap.dll php_mbstring.dll php_mcrypt.dll php_mhash.dll php_mime_magic.dll php_ming.dll php_pspell.dll php_shmop.dll php_snmp.dll 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/bug.php?id=51298 -- Edit this bug report at http://bugs.php.net/bug.php?id=51298edit=1
Bug #51550 [Opn-Csd]: 'Open php' tag at end of file causes 'syntax error, unexpected $end'
Edit report at http://bugs.php.net/bug.php?id=51550edit=1 ID: 51550 Updated by: degeb...@php.net Reported by: daan at react dot com Summary: 'Open php' tag at end of file causes 'syntax error, unexpected $end' -Status: Open +Status: Closed Type: Bug -Package: Documentation problem +Package: Scripting Engine problem Operating System: Debian Etch PHP Version: 5.2.13 -Assigned To: +Assigned To: degeberg New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2010-04-13 16:23:31] degeb...@php.net Automatic comment from SVN on behalf of degeberg Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=297962 Log: Fixed PHP bug #51550 ('Open php' tag at end of file causes 'syntax error, unexpected ') [2010-04-13 16:10:08] johan...@php.net This is fixed in 5.3 with a new parser. This won't be fixed in 5.2. Maybe the doc team wants to add it to the documentation. [2010-04-13 15:40:13] daan at react dot com Description: This probably is a known effect, but I will just open a bug so it can be documented as such: When you end a file with a PHP open tag '?php', and there is no character beyond the tag the parser chokes with an 'unexpected $end' parse error. Curiously, a short tag '?' (if enabled) used in such a way raises no error. This effect is of course also seen when you eval a string containing an PHP open tag at the end of the string. (from there I originally stumbled on this behaviour) In PHP 5.3 the code behaves as expected, so someone probably already spotted this one, or fixed the parser to be less nitty. Test script: --- ?php Expected result: Nothin Actual result: -- Parse error: syntax error, unexpected $end in test.php on line 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=51550edit=1
Bug #51274 [Opn]: Integer overflow does not cast as float
Edit report at http://bugs.php.net/bug.php?id=51274edit=1 ID: 51274 User updated by: cduncan at regatta dot com Reported by: cduncan at regatta dot com Summary: Integer overflow does not cast as float Status: Open Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.3.2 New Comment: I am now able to reproduce the problem, what extra information do you require to debug? Previous Comments: [2010-03-26 10:17:04] cduncan at regatta dot com Thanks, I was worried I was going mad for a moment there. Unfortunately I can't reproduce it on the machines I'm using at the moment. The machine I was experiencing it on was a production box, so finding time to reproduce it again could be tricky. Once I am able to do so, what extra information would assist in tracking this down? Thanks [2010-03-26 09:24:56] ahar...@php.net Oh, I see what you're getting at now. Sorry about that. I still can't reproduce it, though. [2010-03-26 09:16:37] cduncan at regatta dot com Sorry but I'm misunderstanding what you are telling me. Why is the number reduced to the 32bit limit? (2147483647) Especially if you're saying the only way this could occur is with a 64bit OS? As I stated in my last edit, wouldn't a 64bit OS return: int(2147483648) [2010-03-26 07:50:20] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=296829 Log: Update to the integer type page to make it clearer how overflow works on 32- and 64-bit systems and what the critical thresholds are. Prompted by bug #51274, although not an actual fix for it. [2010-03-26 06:33:35] ahar...@php.net I can't really see any way this could occur other than your server having a 64-bit install of Linux on it. What distribution is the server running, what does uname -m output, and what does configure say the host and target system types are? (Side note: the manual could admittedly be a bit clearer on this; although the fact integer size differs on different platforms is mentioned, it might be useful if the Integer Overflow section actually reiterated it. I'll see about updating it.) 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/bug.php?id=51274 -- Edit this bug report at http://bugs.php.net/bug.php?id=51274edit=1
Bug #51542 [Opn-Bgs]: Overriding method type hint with child interface raises strict standards
Edit report at http://bugs.php.net/bug.php?id=51542edit=1 ID: 51542 Updated by: degeb...@php.net Reported by: mike at mikegerwitz dot com Summary: Overriding method type hint with child interface raises strict standards -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: GNU/Linux PHP Version: 5.3.2 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. When someone receives an instance of a One object, the method signature of foo() tells them that it needs an IOne instance. In Two you further restrict that to an ITwo. Seeing as a Two instance is a One instance, a Two instance will be accepted by people who want a One instance. They cannot know that the parameter requirements have been changed and that is why you get an E_STRICT. Also, this is not just for interfaces, but for classes as well. Previous Comments: [2010-04-12 15:43:13] mike at mikegerwitz dot com Description: When using an interface for type hinting, PHP raises a strict standards warning if an overriding method uses an interface that implements the type hint. In the example below, ITwo implements IOne and method One::foo expects the first argument to implement IOne. Two extends One and expects the first argument to implement ITwo, which implements IOne. This should be allowed, much like it is allowed if the interfaces were simply classes. Test script: --- interface IOne {} interface ITwo extends IOne {} class One { public function foo( IOne $bla ) {} } class Two extends One { public function foo( ITwo $bla ) {} } class Test implements ITwo {} // yet, this does work var_dump( new Test instanceof IOne ); Expected result: bool(true) Actual result: -- PHP Strict Standards: Declaration of Two::foo() should be compatible with that of One::foo() in test.php on line 25 Strict Standards: Declaration of Two::foo() should be compatible with that of One::foo() in test.php on line 25 bool(true) -- Edit this bug report at http://bugs.php.net/bug.php?id=51542edit=1
[PHP-BUG] Req #51551 [NEW]: Include custom HTTP headers in request
From: Operating system: ALL PHP version: 5.3SVN-2010-04-13 (SVN) Package: SOAP related Bug Type: Feature/Change Request Bug description:Include custom HTTP headers in request Description: When creating a soap client, I would also like to be able to identify custom HTTP headers. See attached patch, please include in next release (which will also require the documentation to be included) Test script: --- $client = new SoapClient('http://london:8180/testing/headerserver.php?wsdl', array( trace=true, custom_http_header=New: test header )); -- Edit bug report at http://bugs.php.net/bug.php?id=51551edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51551r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51551r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51551r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51551r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51551r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51551r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51551r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51551r=needscript Try newer version: http://bugs.php.net/fix.php?id=51551r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51551r=support Expected behavior: http://bugs.php.net/fix.php?id=51551r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51551r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51551r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51551r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51551r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51551r=dst IIS Stability: http://bugs.php.net/fix.php?id=51551r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51551r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51551r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51551r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51551r=mysqlcfg
[PHP-BUG] Bug #51552 [NEW]: Modifying debug_backtrace() output causes segmentation fault
From: Operating system: win/linux PHP version: 5.3.2 Package: Reproducible crash Bug Type: Bug Bug description:Modifying debug_backtrace() output causes segmentation fault Description: Under certain conditions, when result from debug_backtrace() function is modified, segmentation fault is triggered. I noticed this error on PHP 5.2.6/Win and PHP 5.3.2/Linux x64. PHP 5.3.2 configure line: './configure' '--with-apxs2=/usr/local/apache22/bin/apxs' '--prefix=/usr/local/php53' '--with-zlib=/usr/' '--with-openssl=no' '--with-mysql=no' '--with-mssql=/usr/local/freetds' '--with-pgsql=/usr/local/pg83' '--with-gd' '--without-sqlite' '--with-pdo-pgsql=/usr/local/pg83' '--disable-tokenizer' '--without-pdo-sqlite' '--disable-xmlreader' '--disable-xmlwriter' '--with-jpeg-dir=/usr' '--disable-filter' '--enable-soap' '--enable-mbstring' '--with-libdir=lib64' '--enable-gd-native-ttf' '--with-freetype-dir=/usr' '--with-oci8=instantclient,/usr/local/lib/oracle11.7' The error is hard to trigger, I narrowed it down to below test case. Points to note: - array_walk with 3 parameters must be used - array_walk must iterate over array with at least 2 elements - walking function creates an object that uses debug_backtrace() and unsets itself from top of the trace (PEAR_Error object does that). - the error has something to do with references, because when walk() uses 3rd parameter by-reference, error disappears. Test script: --- ?php class i_use_backtrace { function __construct() { $this-backtrace = debug_backtrace(); unset($this-backtrace[0]['object']); // PEAR_Error uses the same behaviour! } } // function walk($element, $key, $params) would behave correctly function walk($element, $key, $params) { $r = new i_use_backtrace; // you could also use new PEAR_Error } $a = array(0, 0); array_walk($a, 'walk' , array(0)); Expected result: No output Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/bug.php?id=51552edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51552r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51552r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51552r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51552r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51552r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51552r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51552r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51552r=needscript Try newer version: http://bugs.php.net/fix.php?id=51552r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51552r=support Expected behavior: http://bugs.php.net/fix.php?id=51552r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51552r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51552r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51552r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51552r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51552r=dst IIS Stability: http://bugs.php.net/fix.php?id=51552r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51552r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51552r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51552r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51552r=mysqlcfg
Bug #51542 [Com]: Overriding method type hint with child interface raises strict standards
Edit report at http://bugs.php.net/bug.php?id=51542edit=1 ID: 51542 Comment by: mike at mikegerwitz dot com Reported by: mike at mikegerwitz dot com Summary: Overriding method type hint with child interface raises strict standards Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: GNU/Linux PHP Version: 5.3.2 New Comment: Ah - seems you are correct. I must have tested improperly. I was not aware that the strict standard warning was raised for classes as well. I'm aware of the design flaws in the above example; I thought PHP was just behaving inconsistently between classes and interfaces. Looks good, then. Previous Comments: [2010-04-13 16:52:49] degeb...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. When someone receives an instance of a One object, the method signature of foo() tells them that it needs an IOne instance. In Two you further restrict that to an ITwo. Seeing as a Two instance is a One instance, a Two instance will be accepted by people who want a One instance. They cannot know that the parameter requirements have been changed and that is why you get an E_STRICT. Also, this is not just for interfaces, but for classes as well. [2010-04-12 15:43:13] mike at mikegerwitz dot com Description: When using an interface for type hinting, PHP raises a strict standards warning if an overriding method uses an interface that implements the type hint. In the example below, ITwo implements IOne and method One::foo expects the first argument to implement IOne. Two extends One and expects the first argument to implement ITwo, which implements IOne. This should be allowed, much like it is allowed if the interfaces were simply classes. Test script: --- interface IOne {} interface ITwo extends IOne {} class One { public function foo( IOne $bla ) {} } class Two extends One { public function foo( ITwo $bla ) {} } class Test implements ITwo {} // yet, this does work var_dump( new Test instanceof IOne ); Expected result: bool(true) Actual result: -- PHP Strict Standards: Declaration of Two::foo() should be compatible with that of One::foo() in test.php on line 25 Strict Standards: Declaration of Two::foo() should be compatible with that of One::foo() in test.php on line 25 bool(true) -- Edit this bug report at http://bugs.php.net/bug.php?id=51542edit=1
Bug #51362 [Com]: var_export() second argument ignored on recursion fatal error
Edit report at http://bugs.php.net/bug.php?id=51362edit=1 ID: 51362 Comment by: neel dot basu dot z at gmail dot com Reported by: daan at react dot com Summary: var_export() second argument ignored on recursion fatal error Status: Assigned Type: Bug Package: Output Control Operating System: Debian Etch PHP Version: 5.2.13 Assigned To: derick New Comment: Looks like similar to http://bugs.php.net/51533 Previous Comments: [2010-03-23 12:40:11] daan at react dot com Description: When calling var_export() on a recursive array, with the 'return' parameter set to true, a partial var_exported string is echoed and then a fatal error is raised. A more correct handling should be to just raise the php fatal error, not output the partial string. (sensitive data might be accidentally shown, for example) Test script: --- $recursive = array(); $recursive[] = $recursive; $test = var_export($recursive, true); Expected result: Fatal error: Nesting level too deep - recursive dependency? in test.php on line x Actual result: -- array ( 0 = array ( 0 = array ( 0 = array ( 0 = array ( Fatal error: Nesting level too deep - recursive dependency? in test.php on line x -- Edit this bug report at http://bugs.php.net/bug.php?id=51362edit=1
Bug #45711 [Com]: Undefined References
Edit report at http://bugs.php.net/bug.php?id=45711edit=1 ID: 45711 Comment by: tkevans at tkevans dot com Reported by: dmass83 at hotmail dot com Summary: Undefined References Status: No Feedback Type: Bug Package: Compile Failure Operating System: Solaris 10 PHP Version: 5.2.6 New Comment: Still seems to be a problem with 5.3.2, AIX 5.3, and OpenSSL 1.0 Previous Comments: [2009-07-24 17:41:10] mrpalassis at hotmail dot com Some more info... These symbols do show in the compiled openssl binaries: $ nm $APACHE_HOME/lib/libcrypto.so | egrep EVP_MD_size|EVP_CIPHER_ [6239] |761792| 88|FUNC |GLOB |3|14 |EVP_CIPHER_asn1_to_param [4525] |762432| 8|FUNC |GLOB |3|14 |EVP_CIPHER_block_size [4548] |762464| 12|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_block_size [6291] |762496| 8|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_cipher [3934] |744576| 184|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_cleanup [5938] |763040| 16|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_clear_flags [3092] |744320| 176|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_ctrl [6158] |744512| 12|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_flags [4515] |732672| 44|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_free [6057] |762560| 8|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_get_app_data [3581] |744288| 24|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_init [6406] |744544| 12|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_iv_length [5648] |762688| 8|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_key_length [3740] |730592| 68|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_new [3789] |762720| 12|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_nid [6103] |732960| 68|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_rand_key [3278] |762592| 8|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_set_app_data [4757] |763008| 16|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_set_flags [6182] |732736| 144|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_set_key_length [4827] |732896| 40|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_set_padding [] |763072| 12|FUNC |GLOB |3|14 |EVP_CIPHER_CTX_test_flags [3215] |762528| 8|FUNC |GLOB |3|14 |EVP_CIPHER_flags [3739] |761600| 172|FUNC |GLOB |3|14 |EVP_CIPHER_get_asn1_iv [4247] |762624| 8|FUNC |GLOB |3|14 |EVP_CIPHER_iv_length [3420] |762656| 8|FUNC |GLOB |3|14 |EVP_CIPHER_key_length [5320] |745792| 8|FUNC |GLOB |3|14 |EVP_CIPHER_nid [4635] |762016| 88|FUNC |GLOB |3|14 |EVP_CIPHER_param_to_asn1 [4821] |761888| 128|FUNC |GLOB |3|14 |EVP_CIPHER_set_asn1_iv [3851] |762112| 316|FUNC |GLOB |3|14 |EVP_CIPHER_type [4440] |762848| 8|FUNC |GLOB |3|14 |EVP_MD_size [4664] |897184| 812|FUNC |GLOB |3|14 |PEM_get_EVP_CIPHER_INFO $ nm $APACHE_HOME/lib/libssl.so | egrep EVP_MD_size|EVP_CIPHER_ [786] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_block_size [1324] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_CTX_block_size [639] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_CTX_cipher [1185] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_CTX_cleanup [982] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_CTX_init [1139] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_CTX_iv_length [801] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_CTX_key_length [660] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_flags [823] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_iv_length [873] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_CIPHER_key_length [1132] | 0| 0|FUNC |GLOB |0|UNDEF |EVP_MD_size Also looks like some others have had similar problems: http://marc.info/?l=php-installm=119696768506493w=2 http://www.phpbuilder.com/board/archive/index.php/t-10357481.html [2009-07-24 17:30:46] mrpalassis at hotmail dot com We experience the same error with PHP 5.3.0: Undefined first referenced symbol in file EVP_MD_size ext/openssl/.libs/openssl.o EVP_CIPHER_iv_lengthext/openssl/.libs/openssl.o EVP_CIPHER_block_size ext/openssl/.libs/openssl.o EVP_CIPHER_key_length ext/openssl/.libs/openssl.o EVP_CIPHER_CTX_block_size ext/openssl/.libs/openssl.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status make: ***
Bug #51546 [Bgs]: If shorthand statement
Edit report at http://bugs.php.net/bug.php?id=51546edit=1 ID: 51546 User updated by: michaelozeryansky at hotmail dot com Reported by: michaelozeryansky at hotmail dot com Summary: If shorthand statement Status: Bogus Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.2.13 New Comment: Thank you, I was forgot to mention if i used parenthesis then it works fine, but I still thought there was an issue. Now I know, and thank you. Previous Comments: [2010-04-13 05:52:54] ahar...@php.net As the note at the end of the manual page at http://au2.php.net/ternary hints at, the associativity of the ternary operator is not particularly obvious. We can't change this now due to potential backward compatibility issues. [2010-04-13 04:23:52] michaelozeryansky at hotmail dot com Description: When I use nested shorthand if statements the result doesn't seem to follow what I expected. I am not sure if this is a bug, but the results are different in other languages. Test script: --- ?php var_dump ((true) ?a:(true) ?b:c) ; // b var_dump ((true) ?a:(false)?b:c) ; // b var_dump ((false)?a:(true) ?b:c) ; // b var_dump ((false)?a:(false)?b:c) ; // c ? I wrote a c++ script to see what the results should be in another language cout ((true) ?a:(true) ?b:c) endl; // result = a cout ((true) ?a:(false)?b:c) endl; // result = a cout ((false)?a:(true) ?b:c) endl; // result = b cout ((false)?a:(false)?b:c) endl; // result = c Expected result: The PHP script should print out: a a b c Actual result: -- In the comments behind each line -- Edit this bug report at http://bugs.php.net/bug.php?id=51546edit=1
Bug #51146 [Opn]: mcrypt doesn't do OFB mode correctly
Edit report at http://bugs.php.net/bug.php?id=51146edit=1 ID: 51146 User updated by: zelnaga at gmail dot com Reported by: zelnaga at gmail dot com Summary: mcrypt doesn't do OFB mode correctly Status: Open Type: Bug Package: mcrypt related Operating System: Windows XP PHP Version: 5.3.1 New Comment: I was comparing mcrypt against openssl_encrypt() and... well, either OpenSSL is wrong or mcrypt is wrong: ?php $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; echo bin2hex(openssl_encrypt(\0\0\0\0\0\0\0\0, 'DES-OFB', '', true)) . \r\n; echo bin2hex(openssl_encrypt(\0\0\0\0\0\0\0\0, 'DES-CFB', '', true)) . \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CBC, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', 'ctr', ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo bin2hex(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); ? ie. mcrypt, in CTR, CBC and ECB modes equal OpenSSL in OFB and CFB modes but not mcrypt in OFB and CFB modes. In other words, OpenSSL's OFB != mcrypt's OFB and they should. Previous Comments: [2010-02-26 16:16:56] zelnaga at gmail dot com As far as I know, the IV is also used for the first round, so I am not sure if your statement holds up. Ummm... the IV - as defined in mcrypt_generic_init - is only used in the first round. Per wikipedia, the first block against which the plaintext is XOR'd is the IV encrypted with the key. That's true in both CFB and OFB modes of operation. The difference between CFB and OFB is what subsequent blocks encrypt for the keystream. So, per that, the first block should be the same. And as for my first bug report... ?php $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo urlencode(mcrypt_generic($td, '')); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CBC, ''); mcrypt_generic_init($td, '', \0\0\0\0\0\0\0\0); echo urlencode(mcrypt_generic($td, '')); echo \r\n; $td = mcrypt_module_open(MCRYPT_DES, '', 'ctr', ''); mcrypt_generic_init($td, '', ''); echo urlencode(mcrypt_generic($td, \0\0\0\0\0\0\0\0)); ? All of those should produce the same ciphertext. As it stands, only ecb, cbc and ctr produce the same ciphertext. ofb and cfb produce the same thing as each other (and, for the first block, they should, as I already mentioned), however, they're not producing the same thing as any of the other modes when, in fact, they should be. [2010-02-26 10:54:01] der...@php.net As far as I know, the IV is also used for the first round, so I am not sure if your statement holds up. [2010-02-26 03:28:05] zelnaga at gmail dot com Filing a bug report is going to be a little difficult giving that, near as I can tell, the command line version of mcrypt randomly generates IV's. My first example requires the IV's be of a known value and my second example requires encrypting the same string with two different modes and with the same IV. Also, to be honest, I don't know at all how to intreprete the data the command line version of mcrypt is giving me, anyway. I do the following: mcrypt --algorithm des --mode ecb --no-openpgp test.txt --verbose --bare And I get a 100 byte file. Given that the source file was 16 bytes (- repeated sixteen times), that's a bit odd. Curious to see what the remaining 84 bytes are, I do the following: ?php $td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, ''); mcrypt_generic_init($td, 'test', \0\0\0\0\0\0\0\0); echo mdecrypt_generic($td, file_get_contents('test.txt.nc')); ? And that doesn't produce anything even
[PHP-BUG] Doc #51553 [NEW]: bug in simplexmlelement count example
From: Operating system: PHP version: Irrelevant Package: SimpleXML related Bug Type: Documentation Problem Bug description:bug in simplexmlelement count example Description: In the examples for simplexmlelement-count at http://www.php.net/manual/en/simplexmlelement.count.php, the line: foreach ($elem as $person) { should be: foreach ($elem-children() as $person) { -- Edit bug report at http://bugs.php.net/bug.php?id=51553edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51553r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51553r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51553r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51553r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51553r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51553r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51553r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51553r=needscript Try newer version: http://bugs.php.net/fix.php?id=51553r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51553r=support Expected behavior: http://bugs.php.net/fix.php?id=51553r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51553r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51553r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51553r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51553r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51553r=dst IIS Stability: http://bugs.php.net/fix.php?id=51553r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51553r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51553r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51553r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51553r=mysqlcfg
Doc #51553 [Opn-Bgs]: bug in simplexmlelement count example
Edit report at http://bugs.php.net/bug.php?id=51553edit=1 ID: 51553 Updated by: degeb...@php.net Reported by: sarahnorthway at gmail dot com Summary: bug in simplexmlelement count example -Status: Open +Status: Bogus Type:Documentation Problem Package: SimpleXML related PHP Version: Irrelevant New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. That's not necessary. Did you actually run the code? :) When you iterate over a SimpleXML element, it's its children you'll get. What else should it be? dan...@daniel-laptop:~$ php -v; php test.php PHP 5.3.3-dev (cli) (built: Mar 29 2010 15:35:44) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans Person 1 has got 3 children. Person 2 has got 5 children. Previous Comments: [2010-04-14 00:37:51] sarahnorthway at gmail dot com Description: In the examples for simplexmlelement-count at http://www.php.net/manual/en/simplexmlelement.count.php, the line: foreach ($elem as $person) { should be: foreach ($elem-children() as $person) { -- Edit this bug report at http://bugs.php.net/bug.php?id=51553edit=1
Bug #49349 [Com]: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)
Edit report at http://bugs.php.net/bug.php?id=49349edit=1 ID: 49349 Comment by: jorgecanta47 at hotmail dot com Reported by: raulsalitrero at gmail dot com Summary: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors) Status: Assigned Type: Bug Package: Gettext related Operating System: win32 only - windows xp sp3 PHP Version: 5.3.0 Assigned To: pajoye New Comment: Same problem here with Windows Vista Home Premium, PHP 5.3.1 in XAMPP. Is there any workaround yet? Thanks Previous Comments: [2010-04-05 17:19:37] euridica at narod dot ru Still same in 5.3.2. Translation is done only to default system locale. [2009-12-18 15:44:06] bengibollen at hotmail dot com I have got this problem as well. I'd like to add that the system default language/locale gets translated. But no other languages. Example: I have windows vista, English version, and the system default locale is set to Swedish. The strings that are supposed to be translated are all written in English; _(Hello World!). I have made three translations: ./se/LC_MESSAGES/default.mo ./de/LC_MESSAGES/default.mo ./en/LC_MESSAGES/default.mo /*nonsense words/phrases only for testing*/ I always get the Swedish translation no matter what configurations* I try. If I rename the Swedish translation file I get no translation at all, only the default string. * I've tried all kind of parameters for the following: setlocale(LC_ALL, ...); putenv(LANGUAGE=...); putenv(LANG=...);putenv(LC_ALL=...); [2009-12-08 13:57:06] paulw at torchtrust dot org I am also getting this big. Is it fixed in 5.3.1? Is there a work around? Thanks Paul [2009-10-14 13:45:51] roger dot olivier at gmail dot com As asked by paj...@php.net you can found here an archive with a working script with 5.2.5 and not with 5.3.0 Tested on Xp pro Sp3 http://www.lanforums.com/dl/gettext-setlocale_BUG_5.3.0.zip Unzip and launch index.php. Expected result = print Hello world on screen Actual result = print bonjour le monde on screen [2009-10-02 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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/bug.php?id=49349 -- Edit this bug report at http://bugs.php.net/bug.php?id=49349edit=1
[PHP-BUG] Req #51554 [NEW]: Identifies if a call is static ou 'objective'
From: Operating system: PHP version: Irrelevant Package: Class/Object related Bug Type: Feature/Change Request Bug description:Identifies if a call is static ou 'objective' Description: If a call a method as static, how I can test if is a static call or objective? Well, I think about is_static_call(), example: class A { public function test(){ if(is_static_call()){ echo 'Static method'; } else { echo 'Objective method'; } } } A::test(); // Static method $a = new A; $a-test(); // Objective method Currently I use a 'workarround' for this problem: if($this get_class($this) === get_class()){ // Objective method } This is my sugestion. Bye. -- Edit bug report at http://bugs.php.net/bug.php?id=51554edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51554r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51554r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51554r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51554r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51554r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51554r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51554r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51554r=needscript Try newer version: http://bugs.php.net/fix.php?id=51554r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51554r=support Expected behavior: http://bugs.php.net/fix.php?id=51554r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51554r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51554r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51554r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51554r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51554r=dst IIS Stability: http://bugs.php.net/fix.php?id=51554r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51554r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51554r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51554r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51554r=mysqlcfg
Req #51469 [Com]: why not Inner Classes?
Edit report at http://bugs.php.net/bug.php?id=51469edit=1 ID: 51469 Comment by: david71rj at gmail dot com Reported by: giorgio dot liscio at email dot it Summary: why not Inner Classes? Status: Open Type: Feature/Change Request Package: Class/Object related Operating System: irrelevant PHP Version: 5.3.2 New Comment: You can use namespaces from PHP 5.3, is basically this. See doc. Previous Comments: [2010-04-03 07:55:22] giorgio dot liscio at email dot it Description: hi, some object oriented architectures requires inner classes i'm not good with english language so i write some examples: in a library like PDO, now we can do some like this: class Database { public function prepareSql($sql){ return new Sql($sql)} } class Sql { public function setValue($search, $replace){} public function executeQuery(){return new ExecutedQuery();} } class ExecutedQuery { function fetch() function numRows() // etc } this api allows the developer to instantiate an ExecutedQuery with no Sql parameters escaping (class Sql) so inner classes are useful to make visible classes in some trusted environment: class Database { public function prepareSql($sql){ return new Sql($sql)} class Sql { public function setValue($search, $replace){} public function executeQuery(){return new ExecutedQuery();} class ExecutedQuery { function fetch() function numRows() // etc } } } i've read a lot of rfc on php's wiki but no one talks about inner classes (useful like traits and others new work in progress features) what do you think about this? -- Edit this bug report at http://bugs.php.net/bug.php?id=51469edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: john dot smith dot 1964 at gmail dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: The folk at Mandriva saw the same problem, figured it out and submitted a patch to PHP. I'm confused, because we're certainly still seeing the problem: https://qa.mandriva.com/show_bug.cgi?id=37171 In PHP on Mandriva 2008, some float to string conversions return 0.0: !! In critical software, this can lead to major loss of data or inconsistant results. Previous Comments: [2010-04-13 03:36:47] john dot smith dot 1964 at gmail dot com I am seeing this bug consistently on standard Windows builds such as 5.2.4 and 5.2.13. Our Server is: Windows NT 5.2 build 3790 Sample code is simple: ? echo round(1451,2); ? On 5.2.4 it will result in 1450.:0 every time. On 5.2.4, other such *funny* values are 1701,1821,1951,2091,2101,2111,2121,2341,2351... On 5.2.13,the numbers 1700 and 1900 consistently return colon-ized results. This is a especially problematic, because 1700 and 1900 occur more frequently in our eCommerce app! This issue is a real problem for us. It has been touched on (but not solved) in at least Bugs 46376, 47716, 47304 and 47418. [2010-03-27 14:19:44] johan...@php.net You are mentioned this version information: php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies This version is very different from the versions we provide. a) Ubuntu adds some custom patches b) Suhosin does major changes to the engine c) Xdebug as well as Zend Debugger do changes to our executor unit. All these components aren't supported here. [2010-03-27 12:50:58] codeslinger at compsalot dot com One further note, in the repro above, it has to be exactly 16 nines. by adding or removing a 9, it does not fail. Also, as far as I know, all of the failures have been on 32bit Intel cpu's. This probably will not fail on a 64bit cpu. [2010-03-27 12:22:12] codeslinger at compsalot dot com well, it's hard to prove a negative. but I have run a bunch of tests on the Linux snapshot and it appears to be working fine. A VERY BIG THANKYOU I did not find any windows snapshots, the latest is 5.2.13 from Feb 24. based on the symptoms, my initial assumption was that this was caused by some kind of array corruption, this turned out to be wrong. the actual repro can be boiled down to one line... :-) echo (string) (double) -0.0; With the caveat that there are other values which also trigger this. [2010-03-26 21:37:12] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 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/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1