Req #53946 [PATCH]: add json_encode option for not escaping unnecessary character
Edit report at https://bugs.php.net/bug.php?id=53946edit=1 ID: 53946 Patch added by: ir...@php.net Reported by:christian dot pernot at pingroom dot net Summary:add json_encode option for not escaping unnecessary character Status: Assigned Type: Feature/Change Request Package:JSON related PHP Version:5.3.5 Assigned To:scottmac Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug53946.phpt Revision: 1311574689 URL: https://bugs.php.net/patch-display.php?bug=53946patch=bug53946.phptrevision=1311574689 Previous Comments: [2011-07-19 12:18:06] ir...@php.net Fragment from rfc4627 ( http://www.ietf.org/rfc/rfc4627.txt ) All Unicode characters may be placed within the quotation marks EXCEPT for the characters that MUST BE escaped: quotation mark, reverse solidus, and the control characters (U+ through U+001F). Any character MAY BE escaped. [2011-07-19 12:14:14] ir...@php.net The given option is especially necessary, when json is used in ajax responses. The size of a line decreases approximately twice. I have added a patch which the minimum changes in a code adds support given parameter. This parameter doesn't demand UTF8 to UTF16 encoding. But encoding validate utf8 line, therefore I hadn't touch it for BC. [2011-07-19 12:02:55] ir...@php.net The following patch has been added/updated: Patch Name: json_unescaped_unicode.patch Revision: 1311091375 URL: https://bugs.php.net/patch-display.php?bug=53946patch=json_unescaped_unicode.patchrevision=1311091375 [2011-07-19 12:02:24] ir...@php.net The following patch has been added/updated: Patch Name: bug53946.phpt Revision: 1311091344 URL: https://bugs.php.net/patch-display.php?bug=53946patch=bug53946.phptrevision=1311091344 [2011-07-19 12:01:33] ir...@php.net The following patch has been added/updated: Patch Name: json_unescaped_unicode Revision: 1311091293 URL: https://bugs.php.net/patch-display.php?bug=53946patch=json_unescaped_unicoderevision=1311091293 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 https://bugs.php.net/bug.php?id=53946 -- Edit this bug report at https://bugs.php.net/bug.php?id=53946edit=1
Bug #55211 [PATCH]: ArrayObject::getArrayObject ()
Edit report at https://bugs.php.net/bug.php?id=55211edit=1 ID: 55211 Patch added by: larue...@php.net Reported by:suman dot madavapeddi at gmail dot com Summary:ArrayObject::getArrayObject () Status: Verified Type: Bug Package:SPL related Operating System: windows 7 Professional PHP Version:5.3.6 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: getarraycopy-skip-object-protected-private-properties Revision: 1311575639 URL: https://bugs.php.net/patch-display.php?bug=55211patch=getarraycopy-skip-object-protected-private-propertiesrevision=1311575639 Previous Comments: [2011-07-24 04:17:05] larue...@php.net The following patch has been added/updated: Patch Name: getarraycopy-skip-protected-and-private Revision: 1311481025 URL: https://bugs.php.net/patch-display.php?bug=55211patch=getarraycopy-skip-protected-and-privaterevision=1311481025 [2011-07-14 20:46:31] suman dot madavapeddi at gmail dot com Description: --- From manual page: http://www.php.net/arrayobject.getarraycopy%23Description --- when it is referred to an object it should return only public properties of an object .But, Instead it is returning all the Properties of an Object Test script: --- class MyClass{ public $pbvar = public Variable; private $prvar = Private Variable; protected $pdvar = Protected Variable; } $ar = new ArrayObject( new MyClass()); $arc = $ar-getArrayCopy(); print_r($arc); Expected result: Array ( [pbvar] = public Variable ) Actual result: -- Array ( [pbvar] = public Variable [MyClass5prvar] = Private Variable [*pdvar] = Protected Variable ) -- Edit this bug report at https://bugs.php.net/bug.php?id=55211edit=1
[PHP-BUG] Bug #55278 [NEW]: @ Error control operator prevents creation of variable
From: Operating system: Windows 7 PHP version: 5.3.6 Package: Scripting Engine problem Bug Type: Bug Bug description:@ Error control operator prevents creation of variable Description: When a function is defined with a parameter that is passed by reference, calling the function with a variable that has not been previously set will create that variable (and trigger a warning). After the function is called that variable exists (won't trigger warnings) and holds null or whatever value the function assigned to it. If you try to suppress the warning for the variable that doesn't exist at call time, it will not be created, and trying to access it after the function triggers warnings. It works as expected if you suppress errors on the function call but this is not desirable because it will also hide other errors. Test script: --- ?php function foo($bar) { $bar = 'woo'; } @foo($x); foo(@$y); var_dump($x, $y); Expected result: string(3) woo string(3) woo Actual result: -- Notice: Undefined variable: y in FILE on line LINE string(3) woo NULL -- Edit bug report at https://bugs.php.net/bug.php?id=55278edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55278r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55278r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55278r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55278r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55278r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55278r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55278r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55278r=needscript Try newer version: https://bugs.php.net/fix.php?id=55278r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55278r=support Expected behavior: https://bugs.php.net/fix.php?id=55278r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55278r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55278r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55278r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55278r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55278r=dst IIS Stability: https://bugs.php.net/fix.php?id=55278r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55278r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55278r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55278r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55278r=mysqlcfg
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100edit=1 ID: 32100 Comment by: ninzya at inbox dot lv Reported by:ceefour at gauldong dot net Summary:Request 'finally' support for exceptions Status: Closed Type: Feature/Change Request Package:Feature/Change Request Operating System: * PHP Version:5.* Block user comment: N Private report: N New Comment: ++finally Previous Comments: [2011-07-22 07:53:27] dsberliner at gmail dot com ++ for finally in exception handling. Please reconsider. [2011-05-30 02:53:58] bat at flurf dot net Here's an idea! Find all the people who think finally isn't needed in PHP. Invite them to go back to programming Visual Basic, because they're ignorant. The rest can work on implementing it. Easy! [2011-05-05 11:52:26] ealexs at gmail dot com PHP++ for finally in PHP ;) my code: disableSIPTrunk (10 lines of code) try { // do some stuff } finally { enableSIPTrunk (10 lines of code) } // saves duplicate code and it's very elegant ! [2011-04-05 21:16:06] adam dot pippin at ohmedia dot ca --- Disable user permission checking try { Call a half a dozen methods } finally { Re-enable user permission checking } --- The ten year old discussion I found on the issue (http://marc.info/?l=php-internalsm=96774165717219w=3) doesn't seem terribly applicable to my case. Specifically, it suggests: --- try { ... modify contents ... } catch { ... any error recovery code here ... } ... cleanup code ... --- Except my code doesn't 'recover' from errors. It runs back up the call stack and reports the error to the user. I have absolutely zero use for a catch here. My workaround (which, unlike a basic rethrow preserves the line/file): --- Disable permission checking try { Run methods } catch (Exception $e) { Enable permission checking throw new Exception($e-getMessage(), $e-getCode(), $e); } Enable permission checking --- The workaround simply requires a few extra lines of code and a bunch of duplicated code. But hey, finally isn't required, so it's all good. [2011-03-20 10:44:01] php at techdp dot co dot uk +++ for finally in PHP. It is one of the most elegant and expressive keywords in modern programming, allowing precise capture of error handling semantics, and easy authorship of bug-free code! 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 https://bugs.php.net/bug.php?id=32100 -- Edit this bug report at https://bugs.php.net/bug.php?id=32100edit=1
Bug #54556 [Opn-Ver]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556edit=1 ID: 54556 Updated by: larue...@php.net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice -Status: Open +Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Block user comment: N Private report: N Previous Comments: [2011-04-27 09:56:51] kal dot el dot ias at gmx dot net title changed [2011-04-26 14:42:31] kal dot el dot ias at gmx dot net bump [2011-04-18 10:59:58] kal dot el dot ias at gmx dot net hmm, it's the same for normal variables and it's not an error reporting problem. ?php error_reporting(E_ALL); $foo = null; var_dump($bar, $foo['blah']); OUTPUT: PHP Notice: Undefined variable: bar in /tmp/test2.php on line 5 NULL NULL -- well, i had the feeling that array access on null values would cause an notice. [2011-04-18 10:23:58] kal dot el dot ias at gmx dot net Description: see script Test script: --- ?php class Foo { private $bar; function nonotice(){ var_dump($this-bar['yeah']); } } $foo = new Foo(); $foo-nonotice(); Expected result: notice: access to undefined array blah Actual result: -- NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=54556edit=1
Bug #54556 [PATCH]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556edit=1 ID: 54556 Patch added by: larue...@php.net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311586169 URL: https://bugs.php.net/patch-display.php?bug=54556patch=php-5-3-use-a-null-as-array-trigger-noticerevision=1311586169 Previous Comments: [2011-04-27 09:56:51] kal dot el dot ias at gmx dot net title changed [2011-04-26 14:42:31] kal dot el dot ias at gmx dot net bump [2011-04-18 10:59:58] kal dot el dot ias at gmx dot net hmm, it's the same for normal variables and it's not an error reporting problem. ?php error_reporting(E_ALL); $foo = null; var_dump($bar, $foo['blah']); OUTPUT: PHP Notice: Undefined variable: bar in /tmp/test2.php on line 5 NULL NULL -- well, i had the feeling that array access on null values would cause an notice. [2011-04-18 10:23:58] kal dot el dot ias at gmx dot net Description: see script Test script: --- ?php class Foo { private $bar; function nonotice(){ var_dump($this-bar['yeah']); } } $foo = new Foo(); $foo-nonotice(); Expected result: notice: access to undefined array blah Actual result: -- NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=54556edit=1
Bug #54556 [Com]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556edit=1 ID: 54556 Comment by: larue...@php.net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Block user comment: N Private report: N New Comment: I have submit a patch for this. and I think this situation should trigger a notice to help developers aware of this. since this mostly might be bad codes.. Previous Comments: [2011-07-25 05:29:29] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311586169 URL: https://bugs.php.net/patch-display.php?bug=54556patch=php-5-3-use-a-null-as-array-trigger-noticerevision=1311586169 [2011-04-27 09:56:51] kal dot el dot ias at gmx dot net title changed [2011-04-26 14:42:31] kal dot el dot ias at gmx dot net bump [2011-04-18 10:59:58] kal dot el dot ias at gmx dot net hmm, it's the same for normal variables and it's not an error reporting problem. ?php error_reporting(E_ALL); $foo = null; var_dump($bar, $foo['blah']); OUTPUT: PHP Notice: Undefined variable: bar in /tmp/test2.php on line 5 NULL NULL -- well, i had the feeling that array access on null values would cause an notice. [2011-04-18 10:23:58] kal dot el dot ias at gmx dot net Description: see script Test script: --- ?php class Foo { private $bar; function nonotice(){ var_dump($this-bar['yeah']); } } $foo = new Foo(); $foo-nonotice(); Expected result: notice: access to undefined array blah Actual result: -- NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=54556edit=1
[PHP-BUG] Bug #55279 [NEW]: SimpleXml removes line breaks
From: Operating system: Windows PHP version: 5.3.6 Package: SimpleXML related Bug Type: Bug Bug description:SimpleXml removes line breaks Description: SimpleXML seems to ignore/remove line breaks (\n) in the attributes. Line breaks inside an attribute are valid XML, but they're lost when you use SimpleXML to read the XML data. I encountered this problem when reading XML data provided by the Google Webmaster Tools API Test script: --- XML: ?xml version=1.0? feedentry description=this is the first line here's a second line and another! //feed PHP: $xml = simplexml_load_string($xmldata); foreach ($xml-entry as $entry) { $attributes = $entry-attributes(); print_r($attributes); } Expected result: Keep the line breaks from the attribute values after reading the string. $attributes['description'] == this is the first line here's a second line and another!; Actual result: -- The string no longer contains line breaks: $attributes['description'] == this is the first line here's a second line and another!; -- Edit bug report at https://bugs.php.net/bug.php?id=55279edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55279r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55279r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55279r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55279r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55279r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55279r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55279r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55279r=needscript Try newer version: https://bugs.php.net/fix.php?id=55279r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55279r=support Expected behavior: https://bugs.php.net/fix.php?id=55279r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55279r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55279r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55279r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55279r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55279r=dst IIS Stability: https://bugs.php.net/fix.php?id=55279r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55279r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55279r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55279r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55279r=mysqlcfg
Bug #55279 [Opn-Asn]: SimpleXml removes line breaks
Edit report at https://bugs.php.net/bug.php?id=55279edit=1 ID: 55279 Updated by: paj...@php.net Reported by:mathieu at webberig dot be Summary:SimpleXml removes line breaks -Status: Open +Status: Assigned Type: Bug Package:SimpleXML related Operating System: Windows PHP Version:5.3.6 -Assigned To: +Assigned To:rrichards Block user comment: N Private report: N New Comment: As http://www.w3.org/TR/REC-xml/#NT-AttValue says than new lines are valid in attribute values, it seems that almost no parser returns them. This is certainly a problem in libxml itself as simplexml does not transform the values returned by libxml. Assigne to Rob so he can check with the libxml devs, whether we like to change that or not :) Previous Comments: [2011-07-25 06:17:55] mathieu at webberig dot be Description: SimpleXML seems to ignore/remove line breaks (\n) in the attributes. Line breaks inside an attribute are valid XML, but they're lost when you use SimpleXML to read the XML data. I encountered this problem when reading XML data provided by the Google Webmaster Tools API Test script: --- XML: ?xml version=1.0? feedentry description=this is the first line here's a second line and another! //feed PHP: $xml = simplexml_load_string($xmldata); foreach ($xml-entry as $entry) { $attributes = $entry-attributes(); print_r($attributes); } Expected result: Keep the line breaks from the attribute values after reading the string. $attributes['description'] == this is the first line here's a second line and another!; Actual result: -- The string no longer contains line breaks: $attributes['description'] == this is the first line here's a second line and another!; -- Edit this bug report at https://bugs.php.net/bug.php?id=55279edit=1
Req #36944 [PATCH]: strncmp negative len
Edit report at https://bugs.php.net/bug.php?id=36944edit=1 ID: 36944 Patch added by: larue...@php.net Reported by:ms419 at freezone dot co dot uk Summary:strncmp negative len Status: Open Type: Feature/Change Request Package:Strings related Operating System: Debian PHP Version:5.2.6 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-5-3-strncasecmp-supporting-negative-length Revision: 1311592004 URL: https://bugs.php.net/patch-display.php?bug=36944patch=php-5-3-strncasecmp-supporting-negative-lengthrevision=1311592004 Previous Comments: [2008-11-25 18:45:46] ms419 at freezone dot co dot uk I wish to change this bug report to a feature request. I frequently need to check if a string begins or ends with another string. To check if a string begins with another string, I often use strncmp(): ket% php -r 'var_dump(strncmp(HTTP_ACCEPT, HTTP_, 5));' int(0) ket% - but strncmp() is currently not able to check if a string ends with another string: ket% php -r 'var_dump(strncmp(foo_wrapper, _wrapper, -8));' Warning: Length must be greater than or equal to 0 in Command line code on line 1 Call Stack: 0.0002 62840 1. {main}() Command line code:0 0.0002 62952 2. strncmp() Command line code:1 bool(false) ket% I wish strncmp() were able to check if a string ends with another string. [2006-04-05 11:37:45] tony2...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Negative string length is not allowed in this function. I just committed the patch, from now you'll get an error and FALSE in this case. [2006-04-02 00:33:02] ms419 at freezone dot co dot uk Description: strncmp returns incorrect result given negative len - fis% php ?php var_dump(strncmp('foo_wrapper', '_wrapper', -8)); ? int(7) fis% expected - int(0) returned - int(7) Thanks - Jack -- Edit this bug report at https://bugs.php.net/bug.php?id=36944edit=1
Req #36944 [PATCH]: strncmp negative len
Edit report at https://bugs.php.net/bug.php?id=36944edit=1 ID: 36944 Patch added by: larue...@php.net Reported by:ms419 at freezone dot co dot uk Summary:strncmp negative len Status: Open Type: Feature/Change Request Package:Strings related Operating System: Debian PHP Version:5.2.6 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-5-3-strn-case-cmp-supporting-negative-length Revision: 1311593873 URL: https://bugs.php.net/patch-display.php?bug=36944patch=php-5-3-strn-case-cmp-supporting-negative-lengthrevision=1311593873 Previous Comments: [2011-07-25 11:06:44] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-strncasecmp-supporting-negative-length Revision: 1311592004 URL: https://bugs.php.net/patch-display.php?bug=36944patch=php-5-3-strncasecmp-supporting-negative-lengthrevision=1311592004 [2008-11-25 18:45:46] ms419 at freezone dot co dot uk I wish to change this bug report to a feature request. I frequently need to check if a string begins or ends with another string. To check if a string begins with another string, I often use strncmp(): ket% php -r 'var_dump(strncmp(HTTP_ACCEPT, HTTP_, 5));' int(0) ket% - but strncmp() is currently not able to check if a string ends with another string: ket% php -r 'var_dump(strncmp(foo_wrapper, _wrapper, -8));' Warning: Length must be greater than or equal to 0 in Command line code on line 1 Call Stack: 0.0002 62840 1. {main}() Command line code:0 0.0002 62952 2. strncmp() Command line code:1 bool(false) ket% I wish strncmp() were able to check if a string ends with another string. [2006-04-05 11:37:45] tony2...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Negative string length is not allowed in this function. I just committed the patch, from now you'll get an error and FALSE in this case. [2006-04-02 00:33:02] ms419 at freezone dot co dot uk Description: strncmp returns incorrect result given negative len - fis% php ?php var_dump(strncmp('foo_wrapper', '_wrapper', -8)); ? int(7) fis% expected - int(0) returned - int(7) Thanks - Jack -- Edit this bug report at https://bugs.php.net/bug.php?id=36944edit=1
Req #36944 [PATCH]: strncmp negative len
Edit report at https://bugs.php.net/bug.php?id=36944edit=1 ID: 36944 Patch added by: larue...@php.net Reported by:ms419 at freezone dot co dot uk Summary:strncmp negative len Status: Open Type: Feature/Change Request Package:Strings related Operating System: Debian PHP Version:5.2.6 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug36944.phpt Revision: 1311594024 URL: https://bugs.php.net/patch-display.php?bug=36944patch=bug36944.phptrevision=1311594024 Previous Comments: [2011-07-25 11:37:53] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-strn-case-cmp-supporting-negative-length Revision: 1311593873 URL: https://bugs.php.net/patch-display.php?bug=36944patch=php-5-3-strn-case-cmp-supporting-negative-lengthrevision=1311593873 [2011-07-25 11:06:44] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-strncasecmp-supporting-negative-length Revision: 1311592004 URL: https://bugs.php.net/patch-display.php?bug=36944patch=php-5-3-strncasecmp-supporting-negative-lengthrevision=1311592004 [2008-11-25 18:45:46] ms419 at freezone dot co dot uk I wish to change this bug report to a feature request. I frequently need to check if a string begins or ends with another string. To check if a string begins with another string, I often use strncmp(): ket% php -r 'var_dump(strncmp(HTTP_ACCEPT, HTTP_, 5));' int(0) ket% - but strncmp() is currently not able to check if a string ends with another string: ket% php -r 'var_dump(strncmp(foo_wrapper, _wrapper, -8));' Warning: Length must be greater than or equal to 0 in Command line code on line 1 Call Stack: 0.0002 62840 1. {main}() Command line code:0 0.0002 62952 2. strncmp() Command line code:1 bool(false) ket% I wish strncmp() were able to check if a string ends with another string. [2006-04-05 11:37:45] tony2...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Negative string length is not allowed in this function. I just committed the patch, from now you'll get an error and FALSE in this case. [2006-04-02 00:33:02] ms419 at freezone dot co dot uk Description: strncmp returns incorrect result given negative len - fis% php ?php var_dump(strncmp('foo_wrapper', '_wrapper', -8)); ? int(7) fis% expected - int(0) returned - int(7) Thanks - Jack -- Edit this bug report at https://bugs.php.net/bug.php?id=36944edit=1
Bug #54556 [PATCH]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556edit=1 ID: 54556 Patch added by: larue...@php.net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311595852 URL: https://bugs.php.net/patch-display.php?bug=54556patch=php-5-3-use-a-null-as-array-trigger-noticerevision=1311595852 Previous Comments: [2011-07-25 05:40:56] larue...@php.net I have submit a patch for this. and I think this situation should trigger a notice to help developers aware of this. since this mostly might be bad codes.. [2011-07-25 05:29:29] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311586169 URL: https://bugs.php.net/patch-display.php?bug=54556patch=php-5-3-use-a-null-as-array-trigger-noticerevision=1311586169 [2011-04-27 09:56:51] kal dot el dot ias at gmx dot net title changed [2011-04-26 14:42:31] kal dot el dot ias at gmx dot net bump [2011-04-18 10:59:58] kal dot el dot ias at gmx dot net hmm, it's the same for normal variables and it's not an error reporting problem. ?php error_reporting(E_ALL); $foo = null; var_dump($bar, $foo['blah']); OUTPUT: PHP Notice: Undefined variable: bar in /tmp/test2.php on line 5 NULL NULL -- well, i had the feeling that array access on null values would cause an notice. 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 https://bugs.php.net/bug.php?id=54556 -- Edit this bug report at https://bugs.php.net/bug.php?id=54556edit=1
Bug #53294 [Com]: DateTime-setTimezone() very slow far future dates
Edit report at https://bugs.php.net/bug.php?id=53294edit=1 ID: 53294 Comment by: maarten at react dot com Reported by:maarten at react dot com Summary:DateTime-setTimezone() very slow far future dates Status: Feedback Type: Bug Package:Date/time related Operating System: 64 bit Centos PHP Version:5.2.14 Assigned To:derick Block user comment: N Private report: N New Comment: Tested in 5.3.6, and appears to be fixed. $date = new DateTime('@'.(int)(PHP_INT_MAX / 2)); now takes less than 1ms. :) Previous Comments: [2011-01-22 08:52:50] s...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-11-11 13:55:30] maarten at react dot com Description: DateTime-setTimezone() is very slow on dates in the far future (or history), and the time needed isnt monotonic for greater dates. ie. setTimezone() on a DateTime(PHP_INT_MAX) /* 64 bit max */ takes 0.05 seconds, but takes 250 whole seconds for PHP_INT_MAX/2 . Using the $timezone parameter of the DateTime constructor is always fast though. Test script: --- $start = microtime(1); $date = new DateTime('@'.(PHP_INT_MAX)); // $date = new DateTime('@'.(int)(PHP_INT_MAX / 2)); $date-setTimezone(new DateTimeZone('Europe/Amsterdam')); echo microtime(1) - $start; Expected result: A faster change of the timezone; performance equal to using the constructor parameter -- Edit this bug report at https://bugs.php.net/bug.php?id=53294edit=1
Bug #55272 [Opn-Bgs]: Missing semicolon in DATE_ISO8601 Predefined Constant for date()
Edit report at https://bugs.php.net/bug.php?id=55272edit=1 ID: 55272 Updated by: ahar...@php.net Reported by:steve at stringersites dot com Summary:Missing semicolon in DATE_ISO8601 Predefined Constant for date() -Status: Open +Status: Bogus Type: Bug -Package:Unknown/Other Function +Package:Date/time related Operating System: Mac OS X PHP Version:5.3.6 Block user comment: N Private report: N New Comment: ISO 8601 explicitly allows time zone representations to be basic (without the colon), or extended (with the colon). Both are equally valid, and PHP implements the former in that particular constant. Previous Comments: [2011-07-23 20:39:42] steve at stringersites dot com Description: It would appear that there is a mistake in the DATE_ISO8601 predefined constant for the date() function. current output: 2011-07-22T00:00:00-0500 desired output: 2011-07-22T00:00:00-05:00 http://www.php.net/manual/en/class.datetime.php#datetime.constants.iso8601 http://en.wikipedia.org/wiki/ISO_8601 Test script: --- As best as I can tell, there's supposed to be a semicolon between the timezone offset hours:minutes. ?php $d = mktime (0, 0, 0, '03', '08', '2011'); // 2011-03-08T00:00:00-0600 -- actual, incorrect (?) result echo date(DATE_ISO8601, $d).'br'; // 2011-03-08T00:00:00-0600 echo date(Y-m-d\TH:i:sO, $d).'br'; // 2011-03-08T00:00:00-06:00 -- expected result echo date(Y-m-d\TH:i:sP, $d).'br'; ? So the format for DATE_ISO8601 should be Y-m-d\TH:i:sP (capital P at the end), not Y-m-d\TH:i:sO (capital O at the end). Expected result: // 2011-03-08T00:00:00-0600 -- actual, incorrect (?) result echo date(DATE_ISO8601, $d); Actual result: -- // 2011-03-08T00:00:00-06:00 -- expected result echo date(Y-m-d\TH:i:sP, $d); -- Edit this bug report at https://bugs.php.net/bug.php?id=55272edit=1
Bug #55121 [Asn-Fbk]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121edit=1 ID: 55121 Updated by: f...@php.net Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request -Status: Assigned +Status: Feedback Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) Assigned To: moriyoshi Block user comment: N Private report: N New Comment: Could you please try if this fix works on OS X as well? Tested on debian stable. Previous Comments: [2011-07-25 16:45:42] f...@php.net Automatic comment from SVN on behalf of fa Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=313677 Log: Fix #55121 Segfault with multipart/form-data POST [2011-07-20 13:41:49] nbpo...@php.net A similar segfault on OS X 10.6.7 can be caused using the original steps to reproduce: $ curl --form a=b http://127.0.0.1:8000/file.php $ curl http://127.0.0.1:8000/does_not_exist Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0002011b0b30 0x00010024a3b5 in _zend_mm_free_int (heap=0x10100, p=0x1006651e0) at zend_alloc.c:2097 2097heap-size -= size; (gdb) bt #0 0x00010024a3b5 in _zend_mm_free_int (heap=0x10100, p=0x1006651e0) at zend_alloc.c:2097 #1 0x00010021e6af in destroy_uploaded_files_hash () at rfc1867.c:199 #2 0x00010021b252 in sapi_deactivate () at SAPI.c:535 #3 0x0001002fd61e in php_cli_server_send_error_page (server=0x7fff5fbfa730, client=0x100b4e6f0, status=404) at php_cli_server.c:1525 #4 0x0001002fb31e in php_cli_server_dispatch [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:1636 #5 0x0001002fb31e in php_cli_server_recv_event_read_request (server=0x7fff5fbfe970, client=0x1006651e0) at php_cli_server.c:1924 #6 0x0001002fcae5 in php_cli_server_do_event_for_each_fd_callback [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2010 #7 0x0001002fcae5 in php_cli_server_do_event_for_each_fd [inlined] () at php_cli_server.c:671 #8 0x0001002fcae5 in php_cli_server_poller_iter_on_active [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2046 #9 0x0001002fcae5 in php_cli_server_do_event_loop [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2036 #10 0x0001002fcae5 in do_cli_server (argc=4, argv=0x10) at php_cli_server.c:2147 #11 0x0001002f6aa4 in main (argc=1606415328, argv=0x7fff5fbff400) at php_cli.c:1359 [2011-07-20 13:09:48] f...@php.net I think the culprit lies in php_cli_server_client_populate_request_info in the line request_info-content_type = *val; which doesn't terminate correctly at ; and reads multipart/form-data; boundary=c1e04e412bff instead of multipart/form-data; [2011-07-20 11:21:47] nbpo...@php.net Hmm, previous test-case is no longer working for me either. Try the following: $ curl --form a=b http://localhost:8000/file.php; $ curl http://localhost:8000/file2.php; $ curl http://localhost:8000/file2.php; $ curl --form a=b http://localhost:8000/file.php; It results in a different segfault. Program received signal SIGSEGV, Segmentation fault. _zend_mm_alloc_int (heap=0x8649170, size=40) at /home/nbpoole/Desktop/php/php5.4-201107201430/Zend/zend_alloc.c:1906 1906heap-cache[index] = best_fit-prev_free_block; (gdb) bt #0 _zend_mm_alloc_int (heap=0x8649170, size=40) at /home/nbpoole/Desktop/php/php5.4-201107201430/Zend/zend_alloc.c:1906 #1 0x082a79f0 in _ecalloc (nmemb=1, size=40) at /home/nbpoole/Desktop/php/php5.4-201107201430/Zend/zend_alloc.c:2556 #2 0x08275fc5 in multipart_buffer_new (content_type_dup=value optimized out, arg=0xb7fc42f8) at /home/nbpoole/Desktop/php/php5.4- 201107201430/main/rfc1867.c:283 #3 rfc1867_post_handler (content_type_dup=value optimized out, arg=0xb7fc42f8) at /home/nbpoole/Desktop/php/php5.4- 201107201430/main/rfc1867.c:749 #4 0x08273b46 in sapi_handle_post (arg=0xb7fc42f8) at /home/nbpoole/Desktop/php/php5.4-201107201430/main/SAPI.c:182 #5 0x0827a628 in php_default_treat_data (arg=0, str=0x0, destArray=0x0) at /home/nbpoole/Desktop/php/php5.4-201107201430/main/php_variables.c:330 #6 0x082792aa in php_auto_globals_create_post (name=0xb7ea9bf4 _POST, name_len=5) at /home/nbpoole/Desktop/php/php5.4- 201107201430/main/php_variables.c:690 #7 0x082a7d45 in zend_auto_global_init (auto_global=0x86524b8) at
Bug #55238 [Opn]: Configure throws segfault with libc-client2007e
Edit report at https://bugs.php.net/bug.php?id=55238edit=1 ID: 55238 Updated by: f...@php.net Reported by:k dot joe at freemail dot hu Summary:Configure throws segfault with libc-client2007e Status: Open Type: Bug Package:*Compile Issues Operating System: Debian GNU/Linux 6.0.2 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Didn't throw a segfault for me (same debian+libc-client, only 32bit), instead (with trunk) I got this (configure exited with code 1): checking for U8T_DECOMPOSE... configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. In config.log I have: | #define HAVE_IMAP 1 | #define HAVE_NEW_MIME2TEXT 1 | /* end confdefs.h. */ | | #include c-client.h | | int | main () | { | | int i = U8T_CANONICAL; | | ; | return 0; | } configure:49601: result: configure:49606: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. Previous Comments: [2011-07-19 06:54:00] k dot joe at freemail dot hu /usr/src/php-5.3.7RC3/a# gdb conftest This GDB was configured as x86_64-linux-gnu. Reading symbols from /usr/src/php-5.3.7RC3/a/conftest...done. (gdb) run Starting program: /usr/src/php-5.3.7RC3/a/conftest [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x77b147b8 in utf8_to_mutf7 () from /usr/lib/libc-client.so.2007e (gdb) bt #0 0x77b147b8 in utf8_to_mutf7 () from /usr/lib/libc-client.so.2007e #1 0x00400a3c in main () at configure:50618 [2011-07-19 06:27:37] k dot joe at freemail dot hu Description: Configure with imap throws segfaults into the underlying system (when testing with conftest files), but the configuring and compiling continues fine. # lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 6.0.2 (squeeze) Release:6.0.2 Codename: squeeze # uname -a Linux titan-debian6 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux # dpkg -l | grep libc-client ii libc-client2007e8:2007e~dfsg-3.1 ii libc-client2007e-dev8:2007e~dfsg-3.1 Tested PHP versions: PHP 5.3.3 PHP 5.3.6 PHP 5.3.7RC3 PHP 5.4.0alpha2 PHP 201107190830 (snapshot) Test script: --- simply run: ./configure --with-imap --with-imap-ssl --with-kerberos Expected result: Expecting failed configure or display an error. Actual result: -- reproducible dmesg output: conftest[21201]: segfault at 1 ip 7fe3a8b8a7b8 sp 7f905ae0 error 4 in libc-client.so.2007e.0[7fe3a8b48000+102000] gdb output (don't have debug info): # gdb -c core This GDB was configured as x86_64-linux-gnu. Core was generated by `./conftest'. Program terminated with signal 11, Segmentation fault. #0 0x7fe3a8b8a7b8 in ?? () -- Edit this bug report at https://bugs.php.net/bug.php?id=55238edit=1
Req #52982 [Com]: Expose php_session_active to userland via new function (patch included)
Edit report at https://bugs.php.net/bug.php?id=52982edit=1 ID: 52982 Comment by: php dot net at kenman dot net Reported by:php dot net at kenman dot net Summary:Expose php_session_active to userland via new function (patch included) Status: Assigned Type: Feature/Change Request Package:Session related PHP Version:5.3.3 Assigned To:kalle Block user comment: N Private report: N New Comment: Any update on this? Simple request; I'm not exactly sure what all Kalle was speaking to WRT expose the other values, but what I'm requested here is a tiny piece of functionality, and that is *all* that is being requested. Previous Comments: [2010-10-05 07:34:11] php dot net at kenman dot net pajoye, I'm not sure if you understand which problem I'm trying to address here; it's not whether or not session_start() was successful, it's whether or not there is a current active session. Many times, in frameworks or other large-scale applications, you have no way of knowing whether session_start() has already been called. You cannot rely on session_id(), SID, session_start(), $_SESSION, or any other session functions or session functionality (that I'm aware of) to tell me yes, you already have a session open or no, you do not have a session open _before_ I call session_start(). [2010-10-04 12:15:56] paj...@php.net The notice is documented and can be disabled using the display error settings. To detect whether or not session_start was successful, you have to test its return value (as of 5.3.0). It is actually a documentation problem as the examples in the manual does not check the return values (maybe add one on top of them using 5.3+). [2010-10-04 10:31:43] ka...@php.net If we are going to expose php_session_active, we might aswell expose the other values. I will cook up a patch and apply it to trunk shortly [2010-10-04 04:45:37] php dot net at kenman dot net Description: Attempting to start a session after a session has already been started raises an E_NOTICE, however, there is no sane way to check if a session has already been started. The only ways that I could devise were using the shut-up op (@) or by creating wrapper functions around all of the session functions. This is extreme because there exists in the PHP source, code which can do this; my patch exposes this code for userland comsumption. More info: http://stackoverflow.com/questions/3788369/how-to-tell-if-a-session-is-active Test script: --- session_start(); // 1000's of lines of code, which may/may not have closed the session session_start(); // how to tell if a session is active here? Expected result: Should be able to ask PHP whether or not it knows of an active session. Actual result: -- Notice: A session had already been started - ignoring session_start() -- Edit this bug report at https://bugs.php.net/bug.php?id=52982edit=1
Bug #55272 [Bgs]: Missing semicolon in DATE_ISO8601 Predefined Constant for date()
Edit report at https://bugs.php.net/bug.php?id=55272edit=1 ID: 55272 User updated by:steve at stringersites dot com Reported by:steve at stringersites dot com Summary:Missing semicolon in DATE_ISO8601 Predefined Constant for date() Status: Bogus Type: Bug Package:Date/time related Operating System: Mac OS X PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Got it. Note that the Google Checkout XML API rejects the semicolon-less timestamp using the predefined constant. The only format it accepts is Y-m-d\TH:i:sP. Not that you're responsible for what Google does, but it's something to think about where the theoretical and practical collide. Previous Comments: [2011-07-25 16:38:00] ahar...@php.net ISO 8601 explicitly allows time zone representations to be basic (without the colon), or extended (with the colon). Both are equally valid, and PHP implements the former in that particular constant. [2011-07-23 20:39:42] steve at stringersites dot com Description: It would appear that there is a mistake in the DATE_ISO8601 predefined constant for the date() function. current output: 2011-07-22T00:00:00-0500 desired output: 2011-07-22T00:00:00-05:00 http://www.php.net/manual/en/class.datetime.php#datetime.constants.iso8601 http://en.wikipedia.org/wiki/ISO_8601 Test script: --- As best as I can tell, there's supposed to be a semicolon between the timezone offset hours:minutes. ?php $d = mktime (0, 0, 0, '03', '08', '2011'); // 2011-03-08T00:00:00-0600 -- actual, incorrect (?) result echo date(DATE_ISO8601, $d).'br'; // 2011-03-08T00:00:00-0600 echo date(Y-m-d\TH:i:sO, $d).'br'; // 2011-03-08T00:00:00-06:00 -- expected result echo date(Y-m-d\TH:i:sP, $d).'br'; ? So the format for DATE_ISO8601 should be Y-m-d\TH:i:sP (capital P at the end), not Y-m-d\TH:i:sO (capital O at the end). Expected result: // 2011-03-08T00:00:00-0600 -- actual, incorrect (?) result echo date(DATE_ISO8601, $d); Actual result: -- // 2011-03-08T00:00:00-06:00 -- expected result echo date(Y-m-d\TH:i:sP, $d); -- Edit this bug report at https://bugs.php.net/bug.php?id=55272edit=1
Bug #55121 [Fbk]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121edit=1 ID: 55121 Updated by: nbpo...@php.net Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request Status: Feedback Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) Assigned To: moriyoshi Block user comment: N Private report: N New Comment: Tested latest snapshot on OS X. Same backtrace. Previous Comments: [2011-07-25 16:47:21] f...@php.net Could you please try if this fix works on OS X as well? Tested on debian stable. [2011-07-25 16:45:42] f...@php.net Automatic comment from SVN on behalf of fa Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=313677 Log: Fix #55121 Segfault with multipart/form-data POST [2011-07-20 13:41:49] nbpo...@php.net A similar segfault on OS X 10.6.7 can be caused using the original steps to reproduce: $ curl --form a=b http://127.0.0.1:8000/file.php $ curl http://127.0.0.1:8000/does_not_exist Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0002011b0b30 0x00010024a3b5 in _zend_mm_free_int (heap=0x10100, p=0x1006651e0) at zend_alloc.c:2097 2097heap-size -= size; (gdb) bt #0 0x00010024a3b5 in _zend_mm_free_int (heap=0x10100, p=0x1006651e0) at zend_alloc.c:2097 #1 0x00010021e6af in destroy_uploaded_files_hash () at rfc1867.c:199 #2 0x00010021b252 in sapi_deactivate () at SAPI.c:535 #3 0x0001002fd61e in php_cli_server_send_error_page (server=0x7fff5fbfa730, client=0x100b4e6f0, status=404) at php_cli_server.c:1525 #4 0x0001002fb31e in php_cli_server_dispatch [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:1636 #5 0x0001002fb31e in php_cli_server_recv_event_read_request (server=0x7fff5fbfe970, client=0x1006651e0) at php_cli_server.c:1924 #6 0x0001002fcae5 in php_cli_server_do_event_for_each_fd_callback [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2010 #7 0x0001002fcae5 in php_cli_server_do_event_for_each_fd [inlined] () at php_cli_server.c:671 #8 0x0001002fcae5 in php_cli_server_poller_iter_on_active [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2046 #9 0x0001002fcae5 in php_cli_server_do_event_loop [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2036 #10 0x0001002fcae5 in do_cli_server (argc=4, argv=0x10) at php_cli_server.c:2147 #11 0x0001002f6aa4 in main (argc=1606415328, argv=0x7fff5fbff400) at php_cli.c:1359 [2011-07-20 13:09:48] f...@php.net I think the culprit lies in php_cli_server_client_populate_request_info in the line request_info-content_type = *val; which doesn't terminate correctly at ; and reads multipart/form-data; boundary=c1e04e412bff instead of multipart/form-data; [2011-07-20 11:21:47] nbpo...@php.net Hmm, previous test-case is no longer working for me either. Try the following: $ curl --form a=b http://localhost:8000/file.php; $ curl http://localhost:8000/file2.php; $ curl http://localhost:8000/file2.php; $ curl --form a=b http://localhost:8000/file.php; It results in a different segfault. Program received signal SIGSEGV, Segmentation fault. _zend_mm_alloc_int (heap=0x8649170, size=40) at /home/nbpoole/Desktop/php/php5.4-201107201430/Zend/zend_alloc.c:1906 1906heap-cache[index] = best_fit-prev_free_block; (gdb) bt #0 _zend_mm_alloc_int (heap=0x8649170, size=40) at /home/nbpoole/Desktop/php/php5.4-201107201430/Zend/zend_alloc.c:1906 #1 0x082a79f0 in _ecalloc (nmemb=1, size=40) at /home/nbpoole/Desktop/php/php5.4-201107201430/Zend/zend_alloc.c:2556 #2 0x08275fc5 in multipart_buffer_new (content_type_dup=value optimized out, arg=0xb7fc42f8) at /home/nbpoole/Desktop/php/php5.4- 201107201430/main/rfc1867.c:283 #3 rfc1867_post_handler (content_type_dup=value optimized out, arg=0xb7fc42f8) at /home/nbpoole/Desktop/php/php5.4- 201107201430/main/rfc1867.c:749 #4 0x08273b46 in sapi_handle_post (arg=0xb7fc42f8) at /home/nbpoole/Desktop/php/php5.4-201107201430/main/SAPI.c:182 #5 0x0827a628 in php_default_treat_data (arg=0, str=0x0, destArray=0x0) at /home/nbpoole/Desktop/php/php5.4-201107201430/main/php_variables.c:330 #6 0x082792aa in php_auto_globals_create_post (name=0xb7ea9bf4 _POST, name_len=5) at
Bug #55121 [Fbk]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121edit=1 ID: 55121 Updated by: nbpo...@php.net Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request Status: Feedback Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) Assigned To: moriyoshi Block user comment: N Private report: N New Comment: OK. I retested again just now with the latest snapshot on both OS X and Ubuntu. No segfaults anymore. Previous Comments: [2011-07-25 18:11:10] nbpo...@php.net Tested latest snapshot on OS X. Same backtrace. [2011-07-25 16:47:21] f...@php.net Could you please try if this fix works on OS X as well? Tested on debian stable. [2011-07-25 16:45:42] f...@php.net Automatic comment from SVN on behalf of fa Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=313677 Log: Fix #55121 Segfault with multipart/form-data POST [2011-07-20 13:41:49] nbpo...@php.net A similar segfault on OS X 10.6.7 can be caused using the original steps to reproduce: $ curl --form a=b http://127.0.0.1:8000/file.php $ curl http://127.0.0.1:8000/does_not_exist Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0002011b0b30 0x00010024a3b5 in _zend_mm_free_int (heap=0x10100, p=0x1006651e0) at zend_alloc.c:2097 2097heap-size -= size; (gdb) bt #0 0x00010024a3b5 in _zend_mm_free_int (heap=0x10100, p=0x1006651e0) at zend_alloc.c:2097 #1 0x00010021e6af in destroy_uploaded_files_hash () at rfc1867.c:199 #2 0x00010021b252 in sapi_deactivate () at SAPI.c:535 #3 0x0001002fd61e in php_cli_server_send_error_page (server=0x7fff5fbfa730, client=0x100b4e6f0, status=404) at php_cli_server.c:1525 #4 0x0001002fb31e in php_cli_server_dispatch [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:1636 #5 0x0001002fb31e in php_cli_server_recv_event_read_request (server=0x7fff5fbfe970, client=0x1006651e0) at php_cli_server.c:1924 #6 0x0001002fcae5 in php_cli_server_do_event_for_each_fd_callback [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2010 #7 0x0001002fcae5 in php_cli_server_do_event_for_each_fd [inlined] () at php_cli_server.c:671 #8 0x0001002fcae5 in php_cli_server_poller_iter_on_active [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2046 #9 0x0001002fcae5 in php_cli_server_do_event_loop [inlined] () at /Users/nbpoole/php-test/php5.4-201107201630/sapi/cli/php_cli_server.c:2036 #10 0x0001002fcae5 in do_cli_server (argc=4, argv=0x10) at php_cli_server.c:2147 #11 0x0001002f6aa4 in main (argc=1606415328, argv=0x7fff5fbff400) at php_cli.c:1359 [2011-07-20 13:09:48] f...@php.net I think the culprit lies in php_cli_server_client_populate_request_info in the line request_info-content_type = *val; which doesn't terminate correctly at ; and reads multipart/form-data; boundary=c1e04e412bff instead of multipart/form-data; 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 https://bugs.php.net/bug.php?id=55121 -- Edit this bug report at https://bugs.php.net/bug.php?id=55121edit=1
Bug #52797 [Com]: crash because of double free
Edit report at https://bugs.php.net/bug.php?id=52797edit=1 ID: 52797 Comment by: osharoiko at gmail dot com Reported by:hossy421 at yahoo dot co dot jp Summary:crash because of double free Status: Feedback Type: Bug Package:Reproducible crash Operating System: FreeBSD 7.3-RELEASE-p2 PHP Version:5.3.3 Block user comment: N Private report: N New Comment: I can confirm that this reproducable problem stil exists in 5.3.6 and the patch provided in this ticket solves the problem. I have a strong feeling that this problem also exists in trunk (thought I didn't check that directly, but I can see on svn.php.net that patch was not committed). Please consider fixing this problem. Previous Comments: [2011-01-29 16:07:23] hossy421 at yahoo dot co dot jp The patch is not applied to the latest snapshot. I believe the problem is still there. [2011-01-29 11:31:48] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-09-08 15:18:45] hossy421 at yahoo dot co dot jp Description: httpd ( Apache 2.2 ) crashes below messages. pid X(httpd), uid 80: exited on signal 11 X is process id of a httpd child process. Test script: --- independent of script. httpd is crashed by any script. for example PukiWiki. Expected result: all script will run without any error. Actual result: -- I've compiled PHP with --enable-debug option. PHP crash with below message. --- Zend/zend_language_scanner.l(704) : Block 0x28f9871c status: Beginning: Freed Start: OK End: Overflown (magic=0x003C instead of 0xC5F842B3) At least 4 bytes overflown --- Zend/zend_language_scanner.l(704) is below code. efree(SCNG(script_org)); `SCNG(script_org)' is saved by `zend_save_lexical_state()' function, and restored by `zend_restore_lexical_state()' function. `SCNG(script_org)' is `unsigned char*', but only the pointers are stored and saved, not the string pointed to. -- Edit this bug report at https://bugs.php.net/bug.php?id=52797edit=1
Req #52982 [Asn]: Expose php_session_active to userland via new function (patch included)
Edit report at https://bugs.php.net/bug.php?id=52982edit=1 ID: 52982 Updated by: ar...@php.net Reported by:php dot net at kenman dot net Summary:Expose php_session_active to userland via new function (patch included) Status: Assigned Type: Feature/Change Request Package:Session related PHP Version:5.3.3 Assigned To:kalle Block user comment: N Private report: N New Comment: If you're trying to establish whether it's safe to start your own session, this patch is deficient because PS(session_status) is not a boolean - it could also be php_session_disabled. I'd imagine robust code to handle this (rather unusual) case where you require a session but don't know if it's present, would be something like: if (session_is_available()) { if (!session_is_active()) { if (headers_sent()) { // bail out } else { session_start(); } } } else { // bail out } We could instead provide a session_status() function which corresponds to the internal enum (returning SESSION_DISABLED, SESSION_NONE or SESSION_ACTIVE.) I assume this is what Kalle was talking about WRT exposing the other values. Both options are trivial patches. The former seems friendlier but more prone to error. Previous Comments: [2011-07-25 17:25:54] php dot net at kenman dot net Any update on this? Simple request; I'm not exactly sure what all Kalle was speaking to WRT expose the other values, but what I'm requested here is a tiny piece of functionality, and that is *all* that is being requested. [2010-10-05 07:34:11] php dot net at kenman dot net pajoye, I'm not sure if you understand which problem I'm trying to address here; it's not whether or not session_start() was successful, it's whether or not there is a current active session. Many times, in frameworks or other large-scale applications, you have no way of knowing whether session_start() has already been called. You cannot rely on session_id(), SID, session_start(), $_SESSION, or any other session functions or session functionality (that I'm aware of) to tell me yes, you already have a session open or no, you do not have a session open _before_ I call session_start(). [2010-10-04 12:15:56] paj...@php.net The notice is documented and can be disabled using the display error settings. To detect whether or not session_start was successful, you have to test its return value (as of 5.3.0). It is actually a documentation problem as the examples in the manual does not check the return values (maybe add one on top of them using 5.3+). [2010-10-04 10:31:43] ka...@php.net If we are going to expose php_session_active, we might aswell expose the other values. I will cook up a patch and apply it to trunk shortly [2010-10-04 04:45:37] php dot net at kenman dot net Description: Attempting to start a session after a session has already been started raises an E_NOTICE, however, there is no sane way to check if a session has already been started. The only ways that I could devise were using the shut-up op (@) or by creating wrapper functions around all of the session functions. This is extreme because there exists in the PHP source, code which can do this; my patch exposes this code for userland comsumption. More info: http://stackoverflow.com/questions/3788369/how-to-tell-if-a-session-is-active Test script: --- session_start(); // 1000's of lines of code, which may/may not have closed the session session_start(); // how to tell if a session is active here? Expected result: Should be able to ask PHP whether or not it knows of an active session. Actual result: -- Notice: A session had already been started - ignoring session_start() -- Edit this bug report at https://bugs.php.net/bug.php?id=52982edit=1
[PHP-BUG] Bug #55283 [NEW]: SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections
From: Operating system: Cent OS PHP version: 5.3.6 Package: MySQLi related Bug Type: Bug Bug description:SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections Description: The MySQLi ignores SSL options set with mysqli_ssl_set() for persistent connections (works fine for non-persistent connections). To reproduce: 1) Configure MySQL server with SSL support (http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html) 2) Run the attached test script Test script: --- ? $host = 'localhost'; $user = 'root'; $pass = ''; $db= null; $port = 3306; $flags = MYSQLI_CLIENT_SSL; /* persistent connection */ $link = mysqli_init(); mysqli_ssl_set($link, null, null, null, null, RC4-MD5); if (mysqli_real_connect($link, 'p:' . $host, $user, $pass, $db, $port, null, $flags)) { $r = $link-query(SHOW STATUS LIKE 'Ssl_cipher'); var_dump($r-fetch_row()); } /* non-persistent connection */ $link = mysqli_init(); mysqli_ssl_set($link, null, null, null, null, RC4-MD5); if (mysqli_real_connect($link, $host, $user, $pass, $db, $port, null, $flags)) { $r = $link-query(SHOW STATUS LIKE 'Ssl_cipher'); var_dump($r-fetch_row()); } Expected result: array(2) { [0]= string(10) Ssl_cipher [1]= string(18) RC4-MD5 } array(2) { [0]= string(10) Ssl_cipher [1]= string(7) RC4-MD5 } Actual result: -- array(2) { [0]= string(10) Ssl_cipher [1]= string(18) DHE-RSA-AES256-SHA } array(2) { [0]= string(10) Ssl_cipher [1]= string(7) RC4-MD5 } -- Edit bug report at https://bugs.php.net/bug.php?id=55283edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55283r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55283r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55283r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55283r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55283r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55283r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55283r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55283r=needscript Try newer version: https://bugs.php.net/fix.php?id=55283r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55283r=support Expected behavior: https://bugs.php.net/fix.php?id=55283r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55283r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55283r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55283r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55283r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55283r=dst IIS Stability: https://bugs.php.net/fix.php?id=55283r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55283r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55283r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55283r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55283r=mysqlcfg
Bug #55283 [Opn]: SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections
Edit report at https://bugs.php.net/bug.php?id=55283edit=1 ID: 55283 User updated by:aleksey at wepay dot com Reported by:aleksey at wepay dot com Summary:SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections Status: Open Type: Bug Package:MySQLi related Operating System: Cent OS PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Please note that while the example shows the problem with the cipher, all other parameters are also ignored. In particular, ssl cert info is critical. Previous Comments: [2011-07-26 00:20:58] aleksey at wepay dot com Description: The MySQLi ignores SSL options set with mysqli_ssl_set() for persistent connections (works fine for non-persistent connections). To reproduce: 1) Configure MySQL server with SSL support (http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html) 2) Run the attached test script Test script: --- ? $host = 'localhost'; $user = 'root'; $pass = ''; $db= null; $port = 3306; $flags = MYSQLI_CLIENT_SSL; /* persistent connection */ $link = mysqli_init(); mysqli_ssl_set($link, null, null, null, null, RC4-MD5); if (mysqli_real_connect($link, 'p:' . $host, $user, $pass, $db, $port, null, $flags)) { $r = $link-query(SHOW STATUS LIKE 'Ssl_cipher'); var_dump($r-fetch_row()); } /* non-persistent connection */ $link = mysqli_init(); mysqli_ssl_set($link, null, null, null, null, RC4-MD5); if (mysqli_real_connect($link, $host, $user, $pass, $db, $port, null, $flags)) { $r = $link-query(SHOW STATUS LIKE 'Ssl_cipher'); var_dump($r-fetch_row()); } Expected result: array(2) { [0]= string(10) Ssl_cipher [1]= string(18) RC4-MD5 } array(2) { [0]= string(10) Ssl_cipher [1]= string(7) RC4-MD5 } Actual result: -- array(2) { [0]= string(10) Ssl_cipher [1]= string(18) DHE-RSA-AES256-SHA } array(2) { [0]= string(10) Ssl_cipher [1]= string(7) RC4-MD5 } -- Edit this bug report at https://bugs.php.net/bug.php?id=55283edit=1
Bug #55278 [Opn-Dup]: @ Error control operator prevents creation of variable
Edit report at https://bugs.php.net/bug.php?id=55278edit=1 ID: 55278 Updated by: larue...@php.net Reported by:lucas at threeamdesign dot com Summary:@ Error control operator prevents creation of variable -Status: Open +Status: Duplicate Type: Bug Package:Scripting Engine problem Operating System: Windows 7 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: this is a duplicate, see #47623 Previous Comments: [2011-07-25 03:22:23] lucas at threeamdesign dot com Description: When a function is defined with a parameter that is passed by reference, calling the function with a variable that has not been previously set will create that variable (and trigger a warning). After the function is called that variable exists (won't trigger warnings) and holds null or whatever value the function assigned to it. If you try to suppress the warning for the variable that doesn't exist at call time, it will not be created, and trying to access it after the function triggers warnings. It works as expected if you suppress errors on the function call but this is not desirable because it will also hide other errors. Test script: --- ?php function foo($bar) { $bar = 'woo'; } @foo($x); foo(@$y); var_dump($x, $y); Expected result: string(3) woo string(3) woo Actual result: -- Notice: Undefined variable: y in FILE on line LINE string(3) woo NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=55278edit=1
Req #55128 [PATCH]: SplFixedArray::fromArray() does not use extended class
Edit report at https://bugs.php.net/bug.php?id=55128edit=1 ID: 55128 Patch added by: larue...@php.net Reported by:ar at ez dot no Summary:SplFixedArray::fromArray() does not use extended class Status: Open Type: Feature/Change Request Package:SPL related Operating System: * PHP Version:5.3.6 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-5-3-splfixedarray-fromarray-should-return-call-scope-instance Revision: 1311658555 URL: https://bugs.php.net/patch-display.php?bug=55128patch=php-5-3-splfixedarray-fromarray-should-return-call-scope-instancerevision=1311658555 Previous Comments: [2011-07-04 09:50:10] ar at ez dot no Description: It would be nice if SplFixedArray::fromArray() returned the child class instance instead of SplFixedArray instance. Test script: --- class FixedCollection extends SplFixedArray { // impl } $collection = FixedCollection::fromArray( array( 22, 42 ) ); if ( 'FixedCollection' !== get_class( $collection ) ) trigger_error( fromArray() does not use 'new static' ) Expected result: I would have expected that function returned an instance of FixedCollection. -- Edit this bug report at https://bugs.php.net/bug.php?id=55128edit=1
Req #55128 [Opn-Ver]: SplFixedArray::fromArray() does not use extended class
Edit report at https://bugs.php.net/bug.php?id=55128edit=1 ID: 55128 Updated by: larue...@php.net Reported by:ar at ez dot no Summary:SplFixedArray::fromArray() does not use extended class -Status: Open +Status: Verified Type: Feature/Change Request Package:SPL related Operating System: * PHP Version:5.3.6 Block user comment: N Private report: N Previous Comments: [2011-07-26 05:35:55] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-splfixedarray-fromarray-should-return-call-scope-instance Revision: 1311658555 URL: https://bugs.php.net/patch-display.php?bug=55128patch=php-5-3-splfixedarray-fromarray-should-return-call-scope-instancerevision=1311658555 [2011-07-04 09:50:10] ar at ez dot no Description: It would be nice if SplFixedArray::fromArray() returned the child class instance instead of SplFixedArray instance. Test script: --- class FixedCollection extends SplFixedArray { // impl } $collection = FixedCollection::fromArray( array( 22, 42 ) ); if ( 'FixedCollection' !== get_class( $collection ) ) trigger_error( fromArray() does not use 'new static' ) Expected result: I would have expected that function returned an instance of FixedCollection. -- Edit this bug report at https://bugs.php.net/bug.php?id=55128edit=1
Req #55128 [Ver-Ana]: SplFixedArray::fromArray() does not use extended class
Edit report at https://bugs.php.net/bug.php?id=55128edit=1 ID: 55128 Updated by: larue...@php.net Reported by:ar at ez dot no Summary:SplFixedArray::fromArray() does not use extended class -Status: Verified +Status: Analyzed Type: Feature/Change Request Package:SPL related Operating System: * PHP Version:5.3.6 Block user comment: N Private report: N Previous Comments: [2011-07-26 05:35:55] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-splfixedarray-fromarray-should-return-call-scope-instance Revision: 1311658555 URL: https://bugs.php.net/patch-display.php?bug=55128patch=php-5-3-splfixedarray-fromarray-should-return-call-scope-instancerevision=1311658555 [2011-07-04 09:50:10] ar at ez dot no Description: It would be nice if SplFixedArray::fromArray() returned the child class instance instead of SplFixedArray instance. Test script: --- class FixedCollection extends SplFixedArray { // impl } $collection = FixedCollection::fromArray( array( 22, 42 ) ); if ( 'FixedCollection' !== get_class( $collection ) ) trigger_error( fromArray() does not use 'new static' ) Expected result: I would have expected that function returned an instance of FixedCollection. -- Edit this bug report at https://bugs.php.net/bug.php?id=55128edit=1