[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
