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
