Req #35957 [Com]: Array literal syntax support
Edit report at https://bugs.php.net/bug.php?id=35957&edit=1
ID: 35957
Comment by: rasmus at mindplay dot dk
Reported by:matt at matttoddphoto dot com
Summary:Array literal syntax support
Status: Wont fix
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Any
PHP Version:6CVS-2006-01-10 (snap)
Block user comment: N
Private report: N
New Comment:
This feature was implemented in PHP 5.4:
http://svn.php.net/viewvc?view=revision&revision=313641
Previous Comments:
[2006-01-10 08:36:34] der...@php.net
This was discussed, and rejected, many times before.
[2006-01-10 08:28:52] matt at matttoddphoto dot com
Description:
It would be lovely to be able to literally define arrays with
simple syntax like the following:
["one", "two", "three"]
instead of the less intuitive:
array("one", "two", "three");
This would simplify creating arrays of arrays (of arrays)
inline for functions. Also, this would help solve the 'named
parameters' request by allowing for an associative array to be
given simply by throwing []s in.
Reproduce code:
---
Here is an example just for the sake of clarity:
$validate = [$_POST['post'], ['title'=>'/[A-Za-z0-9_\?\!\.\#\&\%]+/',
"text"=>'/\w*/', 'user_id'=>'/\d+/']];
This would be in opposition to:
$validate = array($_POST['post'], array('title'=>'/[A-Za-z0-9_\?\!\.\#\&\%]+/',
"text"=>'/.*/', 'user_id'=>'/\d+/'));
You can see how more complex examples can get just that much more complex (the
the nth degree).
--
Edit this bug report at https://bugs.php.net/bug.php?id=35957&edit=1
[PHP-BUG] Bug #60395 [NEW]: Null byte in source causes file to be ignored, no error or warning reported
From: Operating system: any PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Bug Bug description:Null byte in source causes file to be ignored, no error or warning reported Description: NULL bytes in the source code seem to confuse PHP. See test script below. The code in the file is not executed, and no error or warning is shown. The result is the same if you run it from the command line or from a web server (ruling out a web server problem). This bug has been discovered on MacOS X (10.6.8) with a default, unpatched PHP 5.3.6; but it has been reproduced (so far) as well on Debian 2.6.26-2 with the most recent version of PHP. It does not matter where the null byte(s) is/are placed. They can even be inside a comment! I discovered this bug by accident as I had inadvertently copied a NULL-byte into a comment inside a file that I was require()'ing from elsewhere. The require()'d code was not run, but, even with error_reporting(-1), no warning or error message was displayed. I couldn't figure out what was wrong until I looked at the file with a text editor that can make non-printing characters visible. Removing the NULL byte fixed the problem. Test script: --- This is a 1-line PHP script that contains a single NULL byte: http://dl.dropbox.com/u/257587/test.php Just showing printable chars, the contents of this file is: The NULL byte is located after the closing semicolon. (However, the exact location is irrelevant in order to reproduce the bug.) Expected result: The string 'Hi' should be output. Actual result: -- Instead, PHP outputs a number of non-printing characters (usually shown as question marks). Depending on the position and number of NULL bytes in the source code, the output may also be nothing at all. -- Edit bug report at https://bugs.php.net/bug.php?id=60395&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60395&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60395&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60395&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60395&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60395&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60395&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60395&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60395&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60395&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60395&r=support Expected behavior: https://bugs.php.net/fix.php?id=60395&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60395&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60395&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60395&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60395&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60395&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60395&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60395&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60395&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60395&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60395&r=mysqlcfg
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1
ID: 40837
Comment by: martijntje at martijnotto dot nl
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
I have no idea why this bug is closed as 'bogus'. Just because the
documentation
states it is a certain way does not mean that it is right.
I, for one, believe that it should be possible to create both a static and a
member function with the same name. There would never be any confusion as to
which function should be called due to the difference of using the :: or ->
operator.
Previous Comments:
[2007-03-16 17:40:02] he...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2007-03-16 16:44:17] nick dot telford at gmail dot com
Description:
When declaring two functions in a class (methods) non-static and static
functions may not use the same names.
While I understand this, this is essentially wrong since static methods and
non-static methods are entirely different.
This also leads me on to another bug/feature suggestion I'm about to file about
not being able to overload static attributes with __set/__get.
Reproduce code:
---
class Example {
public static function test() {}
public function test() {}
}
$example = new Example();
$example->test();
Example::test();
Expected result:
No errors, all methods called correctly.
Actual result:
--
PHP errors with: Fatal error: Cannot redeclare Example::test()
--
Edit this bug report at https://bugs.php.net/bug.php?id=40837&edit=1
Req->Bug #55788 [Opn->Csd]: test redirects should abide SHOW_ONLY_GROUPS in run-tests.php
Edit report at https://bugs.php.net/bug.php?id=55788&edit=1 ID: 55788 Updated by: fel...@php.net Reported by:tyr...@php.net Summary:test redirects should abide SHOW_ONLY_GROUPS in run-tests.php -Status: Open +Status: Closed -Type: Feature/Change Request +Type: Bug Package:Testing related PHP Version:Irrelevant -Assigned To: +Assigned To:felipe Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-11-26 17:56:29] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=319964 Log: - Fixed bug #55788 (test redirects should abide SHOW_ONLY_GROUPS in run-tests.php) patch by: tyrael at php.net [2011-09-28 23:20:15] tyr...@php.net The following patch has been added/updated: Patch Name: run-tests.php.diff Revision: 1317252015 URL: https://bugs.php.net/patch-display.php?bug=55788&patch=run-tests.php.diff&revision=1317252015 [2011-09-28 23:18:46] tyr...@php.net as Hannes asked, I update the patch with the following: the groupname for redirect is REDIRECT, as it is more clear what it does than --> I also updated the code, so now it prints REDIRECT $tests ($tested [$tested_file]) begin\n instead of --> $tests ($tested [$tested_file]) begin\n so the group name, and the ouput is consistent as for the other groupnames. I also updated the help to list the possible values for -g (aka SHOW_ONLY_GROUPS) [2011-09-26 21:55:08] tyr...@php.net Description: currently the test redirects(show_redirect_start() and show_redirect_ends()) will always print two lines to the output, ignoring the value of SHOW_ONLY_GROUPS. I think that it would be more consistent, if those lines could be controlled the same way, as we do with everything else. this change would only noticeable for those who run the test suite with custom options (passing the SHOW_ONLY_GROUPS environment variable to make test or the argument -g to run-tests.php). the attached patch is pretty straightforward, you can pass the ---> if you need the ---> lines in your testsuite output. -- Edit this bug report at https://bugs.php.net/bug.php?id=55788&edit=1
Bug #54851 [Asn->Csd]: DateTime::createFromFormat, $format=='D' or $format=='l' Always Returns Today.
Edit report at https://bugs.php.net/bug.php?id=54851&edit=1
ID: 54851
Updated by: der...@php.net
Reported by:phpbugs at nicholassloan dot com
Summary:DateTime::createFromFormat, $format=='D' or
$format=='l' Always Returns Today.
-Status: Assigned
+Status: Closed
Type: Bug
Package:Date/time related
Operating System: Mac OS X
PHP Version:trunk-SVN-2011-05-18 (SVN)
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-11-26 16:44:08] der...@php.net
Automatic comment from SVN on behalf of derick
Revision: http://svn.php.net/viewvc/?view=revision&revision=319960
Log: - Fixed bug #54851 (DateTime::createFromFormat() doesn't interpret
"D").
[2011-05-19 15:00:59] mats dot lindh at gmail dot com
The issue seems to be that there is currently no parsing done for the D/l
parameters. I've added a patch and a test that seems to fix the issue.
[2011-05-19 00:51:31] phpbugs at nicholassloan dot com
Description:
If the format only includes a day string ('D' or 'l'), it is ignored, and a
DateTime instance for the current date/time is returned. Maybe I'm a stupid
idiot,
but I would expect either an error, or for it to return a DateTime object for
the
next occurrence of the given day (similar to \DateTime::__construct('Monday');)
Test script:
---
format('D'));
var_dump($date);
var_dump($date->format('D'));
var_dump($date2);
var_dump($date2->format('D'));
Expected result:
I expect the same date/day to be selected in both cases.
Actual result:
--
object(DateTime)#1 (3) {
["date"]=>
string(19) "2011-05-19 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/New_York"
}
string(3) "Thu"
object(DateTime)#2 (3) {
["date"]=>
string(19) "2011-05-18 18:49:33"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/New_York"
}
string(3) "Wed"
--
Edit this bug report at https://bugs.php.net/bug.php?id=54851&edit=1
Bug->Req #55240 [Asn]: DateTime::createFromFormat with format 'd.m.Y Gi' returns wrong date
Edit report at https://bugs.php.net/bug.php?id=55240&edit=1
ID: 55240
Updated by: der...@php.net
Reported by:m dot strucken at binserv dot de
Summary:DateTime::createFromFormat with format 'd.m.Y Gi'
returns wrong date
Status: Assigned
-Type: Bug
+Type: Feature/Change Request
Package:Date/time related
Operating System: Windows Server 2008 R2
PHP Version:5.3.6
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Hi!
I've had a look at this, and now I can tell you what happens.
Without the delimiter, the 800 gets parsed as 80 hours, 0 minutes.
If you add 80 hours to 11.11.2009, that means 3 days, 8 hours, you get
14.11.2009, 8am.
If you call DateTime::getLastError, you see it shows a warning:
derick@whisky:~$ cat /tmp/test.php
format( 'd.m.Y G i' );
?>
derick@whisky:~$ php /tmp/test.php
class DateTime#1 (3) {
public $date => string(19) "2009-11-14 08:00:00"
public $timezone_type => int(3)
public $timezone => string(13) "Europe/London"
}
array(4) {
'warning_count' =>
int(1)
'warnings' =>
array(1) {
[14] =>
string(27) "The parsed time was invalid"
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
}
14.11.2009 8 00
derick@whisky:~$
The parser for "G" parses up to 2 characters, and it doesn't know how to stop
if it encounters something too high. I'm looking at how I can changes this, but
still not break BC in any form. I've changed the bug's status to FR now.
cheers,
Derick
Previous Comments:
[2011-07-19 11:11:45] m dot strucken at binserv dot de
Description:
Having a date without a delimiter between hour and minute and the hour without
leading zero, the returned date from DateTime::createFromFormat() is incorrect
Test script:
---
$dt = DateTime::createFromFormat( 'd.m.Y Gi', '11.11.2009 800' );
echo $dt->format( 'd.m.Y Gi' );
Expected result:
11.11.2009 800
Actual result:
--
14.11.2009 800
--
Edit this bug report at https://bugs.php.net/bug.php?id=55240&edit=1
Bug #49657 [Com]: array_search returns null instead of false
Edit report at https://bugs.php.net/bug.php?id=49657&edit=1 ID: 49657 Comment by: rodrigovb at gmail dot com Reported by:pvenakis at efrontlearning dot net Summary:array_search returns null instead of false Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: windows PHP Version:5.3.0 Block user comment: N Private report: N New Comment: I'd like to advise you about the impact of this change in the company I work. Based on the last return value (FALSE) we had 40 php files with some lines checking the result of array_search (=== false). This is a small company with 30 employees (and 40 php files to be changed). The concern of the owner is if PHP is sustainable enough to keep investing in develop instead of maintenance due to this changes. Please write the change log (or point the link with the log) cointaining the real needs of this ghange. In my point of view the impact of return value changes of any function could be severe, specially in bigger companies. Previous Comments: [2009-09-25 07:14:46] pvenakis at efrontlearning dot net Thanks for the quick response. It's fine that it returns null, but since this changed from 5.2 to 5.3 it would be nice if it were mentioned in the changelog or in the documents. Best Regards, Periklis [2009-09-24 12:17:22] paj...@php.net That's expected. Returning NULL on invalid argument(s) is correct. [2009-09-24 12:03:47] pvenakis at efrontlearning dot net Description: array_search returns false in 5.2.x, null in 5.3.0, when $haystack is not an array Reproduce code: --- $haystack = false; //Anything not an array $result = array_search(1, $haystack); var_dump($result); Expected result: bool(false) Actual result: -- null -- Edit this bug report at https://bugs.php.net/bug.php?id=49657&edit=1
Bug #60393 [Com]: Generating minus-zero with ceil()
Edit report at https://bugs.php.net/bug.php?id=60393&edit=1 ID: 60393 Comment by: anon at anon dot anon Reported by:athlan at vgroup dot pl Summary:Generating minus-zero with ceil() Status: Bogus Type: Bug Package:Math related Operating System: MacOSX Snow Leopard PHP Version:5.3.8 Block user comment: N Private report: N New Comment: That's correct. Like virtually all modern languages and CPUs, PHP implements the representation and behavior of floating-point numbers according to the standard "IEEE 754". Negative zero is a feature of that standard: http://en.wikipedia.org/wiki/Signed_zero Previous Comments: [2011-11-26 15:04:07] cataphr...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. IEEE 754-2008, definition 2.1.25: (...) All floating-point numbers, including zeros and infinities, are signed. [2011-11-26 08:29:34] athlan at vgroup dot pl Description: --- >From manual page: >http://www.php.net/function.ceil#refsect1-function.ceil-unknown --- You can generate a minus-zero, which is invalid number: Test script: --- Expected result: Actual result: -- -- Edit this bug report at https://bugs.php.net/bug.php?id=60393&edit=1
Bug #60393 [Opn->Bgs]: Generating minus-zero with ceil()
Edit report at https://bugs.php.net/bug.php?id=60393&edit=1 ID: 60393 Updated by: cataphr...@php.net Reported by:athlan at vgroup dot pl Summary:Generating minus-zero with ceil() -Status: Open +Status: Bogus Type: Bug Package:Math related Operating System: MacOSX Snow Leopard PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. IEEE 754-2008, definition 2.1.25: (...) All floating-point numbers, including zeros and infinities, are signed. Previous Comments: [2011-11-26 08:29:34] athlan at vgroup dot pl Description: --- >From manual page: >http://www.php.net/function.ceil#refsect1-function.ceil-unknown --- You can generate a minus-zero, which is invalid number: Test script: --- Expected result: Actual result: -- -- Edit this bug report at https://bugs.php.net/bug.php?id=60393&edit=1
Bug #60389 [Com]: Apache http server 2.3.15 won't run with php enabled
Edit report at https://bugs.php.net/bug.php?id=60389&edit=1 ID: 60389 Comment by: info at apachelounge dot com Reported by:hankmanw7 at home dot nl Summary:Apache http server 2.3.15 won't run with php enabled Status: Bogus Type: Bug Package:Apache2 related Operating System: Windows 7 PHP Version:5.4.0RC2 Block user comment: N Private report: N New Comment: Module php5apache2_3.dll for Apache 2.3.15 with PHP version 5.4.0RC2 and 5.3.8 are available. See http://www.apachelounge.com/viewtopic.php?p=19861 Steffen Previous Comments: [2011-11-25 18:26:45] paj...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2011-11-25 18:24:28] hankmanw7 at home dot nl Description: Apache 2.3.15 with PHP version: 5.4.0RC2 To configure apache for php I added the next lines to the httpd.conf: PHPIniDir "c:/php" LoadModule php5_module "c:/php/php5apache2_3.dll" AddType application/x-httpd-php .php I tried to run the apache service from the Apache service monitor, but it failed: The requested operation failed! And Windows event viewer says: The Apache service named reported the following error: >>> httpd.exe: Syntax error on line 149 of C:/Apache23/conf/httpd.conf: Module >>> "sapi\\apache2handler\\mod_php5.c" is not compatible with this version of >>> Apache (found 20110619, need 20111025). Please contact the vendor for the >>> correct version. -- Edit this bug report at https://bugs.php.net/bug.php?id=60389&edit=1
Bug #55836 [Com]: main()-warning
Edit report at https://bugs.php.net/bug.php?id=55836&edit=1
ID: 55836
Comment by: keyboard27 dot 10 at gmail dot com
Reported by:keyboard27 dot 10 at gmail dot com
Summary:main()-warning
Status: Open
Type: Bug
Package:Unknown/Other Function
Operating System: Windows 7
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
Verse = xml node array(size: 22)
//$Book = xml node array(size: 66)
//$book[($book_id-1)] = xml node array(size: 40)
//$xml_books = xml node
//$xml_books->book = xml node array(size:66)
if((int)$Verse_ID >= sizeof($Chap->Verse))
{
if((int)$Chap_ID >= sizeof($Book[($Book_ID-1)]))
{
if((int)$Book_ID == sizeof($xml_Books->Book))
{
$Book_ID = 1;
$Chap_ID = 1;
$Verse_ID = 1;
}
else
{
$Book_ID++;
$Chap_ID = 1;
$Verse_ID = 1;
}
}
else
{
$Chap_ID++;
$Verse_ID = 1;
}
}
else
{
$Verse_ID++;
}
?>
Previous Comments:
[2011-10-03 14:16:40] keyboard27 dot 10 at gmail dot com
is it oke if i would send you the files?
the one is the xml-file which the other file reads and partly displays
it is in dutch, but that shouldn't be a problem
the $Boek_ID var has the value 2, $Hfst_ID is 1 and $Vers_ID is 22, which is
Exodus(book #2) 1:22
[2011-10-03 14:10:15] paj...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2011-10-03 13:47:56] keyboard27 dot 10 at gmail dot com
the actual warning comes from the following line:
"if((int)$Chap_ID >= sizeof($Book[($Book_ID-1)]))"
[2011-10-03 13:45:26] keyboard27 dot 10 at gmail dot com
Sorry for the double code...
[2011-10-03 13:44:17] keyboard27 dot 10 at gmail dot com
Description:
"Warning: main() [function.main]: Cannot add element number
1 when only 0 such elements exist"
I get this error when trying to read from an xml-file.
In the file i need to jump to a parent-element from a child-element.
//Code:
if((int)$Verse_ID >= sizeof($Chap->Verse))
{
if((int)$Chap_ID >= sizeof($Book[($Book_ID-1)]))
{
if((int)$Book_ID == sizeof($xml_Books->Book))
{
$Book_ID = 1;
$Chap_ID = 1;
$Verse_ID = 1;
}
else
{
$Book_ID++;
$Chap_ID = 1;
$Verse_ID = 1;
}
}
else
{
$Chap_ID++;
$Verse_ID = 1;
}
}
else
{
$Verse_ID++;
}
//$Chap, $xml_Books and $Book are xml-nodes
Test script:
---
//Code:
if((int)$Verse_ID >= sizeof($Chap->Verse))
{
if((int)$Chap_ID >= sizeof($Book[($Book_ID-1)]))
{
if((int)$Book_ID == sizeof($xml_Books->Book))
{
$Book_ID = 1;
$Chap_ID = 1;
$Verse_ID = 1;
}
else
{
$Book_ID++;
$Chap_ID = 1;
$Verse_ID = 1;
}
}
else
{
$Chap_ID++;
$Verse_ID = 1;
}
}
else
{
$Verse_ID++;
}
//$Chap, $xml_Books and $Book are xml-nodes
--
Edit this bug report at https://bugs.php.net/bug.php?id=55836&edit=1
[PHP-BUG] Bug #60393 [NEW]: Generating minus-zero with ceil()
From: Operating system: MacOSX Snow Leopard PHP version: 5.3.8 Package: Math related Bug Type: Bug Bug description:Generating minus-zero with ceil() Description: --- >From manual page: http://www.php.net/function.ceil#refsect1-function.ceil-unknown --- You can generate a minus-zero, which is invalid number: Test script: --- Expected result: Actual result: -- -- Edit bug report at https://bugs.php.net/bug.php?id=60393&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60393&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60393&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60393&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60393&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60393&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60393&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60393&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60393&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60393&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60393&r=support Expected behavior: https://bugs.php.net/fix.php?id=60393&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60393&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60393&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60393&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60393&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60393&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60393&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60393&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60393&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60393&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60393&r=mysqlcfg
