#46191 [NEW]: Back-comp break: DOMDocument::saveXML() doesn't accept null anymore
From: zizka at seznam dot cz Operating system: Any PHP version: 5.2.6 PHP Bug Type: DOM XML related Bug description: Back-comp break: DOMDocument::saveXML() doesn't accept null anymore Description: In PHP 5.2.5, DOMDocument::saveXML() accepted null as it's first argument, which has this documentation: Use this parameter to output only a specific node without XML declaration rather than the entire document. In PHP 5.2.6, passing null causes error. Reproduce code: --- // $doc is a DOM document object. return $doc->saveXML(null, LIBXML_NOEMPTYTAG); Expected result: IMHO null is reasonable value, meaning that whole document should be saved. I suggest to fix this backward compatibility break. Actual result: -- Catchable fatal error: Argument 1 passed to DOMDocument::saveXML() must be an instance of DOMNode, null given, called in ...\index.php on line 97 and defined in ...\inc.Menu.php on line 23 -- Edit bug report at http://bugs.php.net/?id=46191&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46191&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46191&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46191&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46191&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46191&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46191&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46191&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46191&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46191&r=support Expected behavior:http://bugs.php.net/fix.php?id=46191&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46191&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46191&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46191&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46191&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46191&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46191&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46191&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46191&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46191&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46191&r=mysqlcfg
#41158 [Asn]: Add MYSQL_CLIENT_MULTI_RESULTS constant
ID: 41158
User updated by: zizka at seznam dot cz
Reported By: zizka at seznam dot cz
Status: Assigned
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.2.1
Assigned To: georg
New Comment:
I also suggest to note in the documentation that when MySQL extension
is used to retrieve multiple results with CLIENT_MULTI_RESULTS flag set,
MySQL returns an error "Commands out of sync".
Previous Comments:
[2007-04-23 18:49:40] zizka at seznam dot cz
For instance, in case of use of Stored Procedure which uses PREPARED
statement which surely can not return a result (not SELECT or SHOW), but
MySQL does not know it and marks the Stored Procedure as returning a
record set, and then throws an exception "can t return a result set in
the given context". With the flag MYSQL_CLIENT_MULTI_RESULTS, PHP is
able to handle a "CALL ..." query without harming anything (tested).
I've seen some other cases when people on the forums use this flag to
allow PHP's MySQL extension use Stored Procedures which for some similar
reason marked as returning a result set but they do not.
This would be needed to document, that the constant is just for such
purposes and the extension is not able to handle multiple results. That
would also bring the information about such MySQL's behavior right into
the PHP manual, what could, in my oppinion, help some programmers
finding their 'bug' causing "can t return a result set in the given
context".
[2007-04-23 09:08:26] [EMAIL PROTECTED]
>Sometimes a situation arises that this constant is needed even
>though multiple results support is not needed.
For instance?
----------------
[2007-04-22 02:28:31] zizka at seznam dot cz
Description:
Please add MYSQL_CLIENT_MULTI_RESULTS to MySQL extension.
Sometimes a situation arises that this constant is needed even though
multiple results support is not needed. Currently everyone has to add
define('MYSQL_CLIENT_MULTI_RESULTS', 131072);
to his code.
Reproduce code:
---
Expected result:
...
Actual result:
--
...
--
Edit this bug report at http://bugs.php.net/?id=41158&edit=1
#41158 [Fbk->Opn]: Add MYSQL_CLIENT_MULTI_RESULTS constant
ID: 41158
User updated by: zizka at seznam dot cz
Reported By: zizka at seznam dot cz
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.2.1
New Comment:
For instance, in case of use of Stored Procedure which uses PREPARED
statement which surely can not return a result (not SELECT or SHOW), but
MySQL does not know it and marks the Stored Procedure as returning a
record set, and then throws an exception "can t return a result set in
the given context". With the flag MYSQL_CLIENT_MULTI_RESULTS, PHP is
able to handle a "CALL ..." query without harming anything (tested).
I've seen some other cases when people on the forums use this flag to
allow PHP's MySQL extension use Stored Procedures which for some similar
reason marked as returning a result set but they do not.
This would be needed to document, that the constant is just for such
purposes and the extension is not able to handle multiple results. That
would also bring the information about such MySQL's behavior right into
the PHP manual, what could, in my oppinion, help some programmers
finding their 'bug' causing "can t return a result set in the given
context".
Previous Comments:
[2007-04-23 09:08:26] [EMAIL PROTECTED]
>Sometimes a situation arises that this constant is needed even
>though multiple results support is not needed.
For instance?
--------------------
[2007-04-22 02:28:31] zizka at seznam dot cz
Description:
Please add MYSQL_CLIENT_MULTI_RESULTS to MySQL extension.
Sometimes a situation arises that this constant is needed even though
multiple results support is not needed. Currently everyone has to add
define('MYSQL_CLIENT_MULTI_RESULTS', 131072);
to his code.
Reproduce code:
---
Expected result:
...
Actual result:
--
...
--
Edit this bug report at http://bugs.php.net/?id=41158&edit=1
#41159 [NEW]: mysql_pconnect() to check flags param, too
From: zizka at seznam dot cz
Operating system: All
PHP version: 5.2.1
PHP Bug Type: MySQL related
Bug description: mysql_pconnect() to check flags param, too
Description:
mysql_pconnect() tries to reuse an exisiting connection with
the same host/port/username/password from connection pool.
This causes PHP programmers wonder why their application do not behave as
they should after changing the flags in their code (like here:
http://bugs.php.net/bug.php?id=29763
). The actual solution is to restart PHP's container or MySQL or KILL the
PHP's threads in MySQL - all of it sometimes unavailable (commercial
hosting).
So I believe mysql_pconnect() should check flags parameter, too.
Reproduce code:
---
$resA = mysql_pconnect('localhost','test','test');
$resB = mysql_pconnect('localhost','test','test', 131072);
echo "A: $resA B: $resB";
Expected result:
Different connections.
Actual result:
--
Same pooled connection.
--
Edit bug report at http://bugs.php.net/?id=41159&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41159&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41159&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41159&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41159&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41159&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41159&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41159&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41159&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41159&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41159&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41159&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41159&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41159&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41159&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41159&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41159&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41159&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41159&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41159&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41159&r=mysqlcfg
#41158 [NEW]: Add MYSQL_CLIENT_MULTI_RESULTS constant
From: zizka at seznam dot cz
Operating system: All
PHP version: 5.2.1
PHP Bug Type: MySQL related
Bug description: Add MYSQL_CLIENT_MULTI_RESULTS constant
Description:
Please add MYSQL_CLIENT_MULTI_RESULTS to MySQL extension.
Sometimes a situation arises that this constant is needed even though
multiple results support is not needed. Currently everyone has to add
define('MYSQL_CLIENT_MULTI_RESULTS', 131072);
to his code.
Reproduce code:
---
Expected result:
...
Actual result:
--
...
--
Edit bug report at http://bugs.php.net/?id=41158&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41158&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41158&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41158&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41158&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41158&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41158&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41158&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41158&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41158&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41158&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41158&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41158&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41158&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41158&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41158&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41158&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41158&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41158&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41158&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41158&r=mysqlcfg
#39708 [WFx]: Confusing error message for empty(func())
ID: 39708 User updated by: zizka at seznam dot cz Reported By: zizka at seznam dot cz Status: Wont fix Bug Type: Unknown/Other Function Operating System: All PHP Version: 6.0.0 New Comment: But this is not the case: I am not trying to change function's return value; empty() is not supposed to write anything, it just examines the variables. So here is the confusion. Previous Comments: [2006-12-01 18:51:33] [EMAIL PROTECTED] The error message is clear enough and is used in all cases when you're trying to change function's return value, like this: [2006-12-01 18:37:57] zizka at seznam dot cz Description: When calling empty() with a return value from function, it says: Can't use method return value in write context It would be definitely less confusing if it said something like: empty() accepts only variables as a parameter. Reproduce code: --- Expected result: Fatal error: empty() accepts only variables as a parameter in ... on line 2 Actual result: -- Fatal error: Can't use method return value in write context in ... on line 2 -- Edit this bug report at http://bugs.php.net/?id=39708&edit=1
#39904 [NEW]: string -> boolean conversion of "\0" could give FALSE
From: zizka at seznam dot cz
Operating system:
PHP version: 5.2.0
PHP Bug Type: Feature/Change Request
Bug description: string -> boolean conversion of "\0" could give FALSE
Description:
It might be useful that (boolean)"\0" would give FALSE.
E.g. MySQL's BIT(1) column type can be used to store boolean values, but
now PHP converts whatever value to TRUE.
Reproduce code:
---
header('Content-Type: text/plain');
echo "\nfalse: ".ord(false);
echo "\ntrue: ".ord(true);
echo "\n\\0: ".(boolean)("\0");
echo "\n\\1: ".(boolean)("\1");
// ord() is here just for thoughts context...
Expected result:
false: 0
true: 49
\0: 0
\1: 1
Actual result:
--
false: 0
true: 49
\0: 1 <- HERE
\1: 1
--
Edit bug report at http://bugs.php.net/?id=39904&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39904&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39904&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39904&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39904&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39904&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39904&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39904&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39904&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39904&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39904&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39904&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39904&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39904&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39904&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39904&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39904&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39904&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39904&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39904&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39904&r=mysqlcfg
#38437 [NEW]: substr() - slightly change its contract
From: zizka at seznam dot cz
Operating system:
PHP version: 5.1.4
PHP Bug Type: Feature/Change Request
Bug description: substr() - slightly change its contract
Description:
string substr ( string string, int start [, int length] )
Currently:
If string is less than *or equal* to start characters long, FALSE will be
returned.
I suggest:
If string is less than start characters long, FALSE will be returned.
The latter is more "ideologically clean". See the behavior of analogical
methods in Java, JavaScript, C, etc. E.g. I did some simple parser, where
the string of the form $ is expected. I wanted to get
, so I did:
if($s !== '' && $s[0] == '$')
$s2 = substr($s, 1);
Then, behaved by Java's String.substring(), I wrote:
if($s2 === '')
// Replace $s2 with some default value;
After several minutes of searching for the bug, I noticed the fact
mentioned above.
Reproduce code:
---
substr("Ahoj", 4);
Expected result:
An empty string.
Actual result:
--
FALSE.
--
Edit bug report at http://bugs.php.net/?id=38437&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38437&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38437&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38437&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38437&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38437&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38437&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38437&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38437&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38437&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38437&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38437&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38437&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38437&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38437&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38437&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38437&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38437&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38437&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38437&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38437&r=mysqlcfg
#38406 [NEW]: PHP crashes when manipulating with SimpleXML object
From: zizka at seznam dot cz Operating system: Windows XP PHP version: 5.1.4 PHP Bug Type: SimpleXML related Bug description: PHP crashes when manipulating with SimpleXML object Description: PHP crashes when manipulating with SimpleXML object. See the code in the testcase. I think it does not concern stack overflow as there is no (obvious) recursion. Reproduce code: --- http://ondra.zizka.cz/projekty/bugs/bug_SimpleXML_crash-testcase.php.txt Expected result: Either a node should be added, or PHP should throw some exception or warning. Actual result: -- Apache thread crashes (Win32 reports illegal operation). Application Failure Apache.exe 2.0.55.0 in php5ts.dll 5.1.4.4 at offset 001ec55b -- Edit bug report at http://bugs.php.net/?id=38406&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38406&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38406&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38406&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38406&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38406&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38406&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38406&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38406&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38406&r=support Expected behavior:http://bugs.php.net/fix.php?id=38406&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38406&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38406&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38406&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38406&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38406&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38406&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38406&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38406&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38406&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38406&r=mysqlcfg
#31659 [Opn]: array_map to take non-array parameters and pass them to the callback function
ID: 31659
User updated by: zizka at seznam dot cz
Reported By: zizka at seznam dot cz
Status: Open
Bug Type:Feature/Change Request
PHP Version: 5.0.1
New Comment:
Another solution is to pass arrays with several identical members:
$a = explode(' ', 'XyX aXb sXs');
$a = array_map('str_replace', Array('X','X','X'),
Array('Y','Y','Y'), $a);
But the arrays are superfluous in this case, as a scalar value would be
enough. And with this case there is a problem that the supplementary
arrays must be of at least the same length as $a:
PHP Manual: "Usually when using two or more arrays, they should be of
equal length because the callback function is applied in parallel to
the corresponding elements. If the arrays are of unequal length, the
shortest one will be extended with empty elements."
Previous Comments:
----------------
[2005-01-22 22:08:44] zizka at seznam dot cz
Description:
array_map could take non-array parameters and pass them to the callback
function in each step.
Example:
$a = explode(' ', 'XyX aXb sXs');
$a = array_map('str_replace', 'X','Y', $a);
That would result in calling:
str_replace('X','Y', $a[...]);
and the result array would be like
Array('YyY', 'aYb', 'sYs');
Now I have to define a callback function for many simple operations
that could be done this way.
Thanks, Ondra Zizka
Reproduce code:
---
$a = explode(' ', 'XyX aXb sXs');
$a = array_map('str_replace', 'X','Y', $a);
print_r($a);
Expected result:
Array([0] => YyY[1] => aYb[2] => sYs)
Actual result:
--
Warning: array_map() [function.array-map.htm]: Argument #2 should be an
array in ...
--
Edit this bug report at http://bugs.php.net/?id=31659&edit=1
#31765 [Bgs]: PHP crashes when executing certain code
ID: 31765
User updated by: zizka at seznam dot cz
Reported By: zizka at seznam dot cz
Status: Bogus
Bug Type: Reproducible crash
Operating System: All
PHP Version: 4.3.10
New Comment:
I see. Thanks for explanation. I thought that PHP handles this
gracefully.
Previous Comments:
[2005-02-06 22:40:55] [EMAIL PROTECTED]
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
Your code ends up executing an recusrsive function (method) call, which
smashes the stack. This is a know behaviour/issue, avoid recursive
function/method calls with over 100-200 recursion levels.
[2005-02-06 17:31:12] zizka at seznam dot cz
Here is the code reduced to 30 lines. It still crashes PHP module, but
I haven't tested it on other platforms. But I suppose the nature of the
bug is the same so it would crash everywhere again.
http://paste.phpfi.com/49791
[2005-01-31 19:36:20] [EMAIL PROTECTED]
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Please supply a SHORT 10-20 line script that can be used to replicate
the problem.
[2005-01-31 14:19:03] ondra at dynawest dot cz
Don't use zizka at seznam. cz - it doesn't work properly... Use ondra
ta dynawest. cz
[2005-01-30 18:42:24] zizka at seznam dot cz
Description:
PHP crashes on my code.
Reproduced on:
Windows 2000 / Apache 1.3.29 / PHP 4.3.6 (Apache mod)
Windows 2000 / Apache 1.3.29 / PHP 4.3.10 (Apache mod)
Windows 2000 / Apache 2.0.52 / PHP 4.3.10 (Apache mod)
Linux hercules 2.4.25 / Apache 1.3.33 / PHP 4.3.10 (Apache mod)
Windows NT 5.2 / Microsoft-IIS 6.0 / PHP Version 4.3.1 (CGI)
Windows 2000's report (transl. from Czech):
Event type: Chyba
Event source: Service Control Manager
Kategorie události: Není k dispozici
Event ID: 7024
Date: 29.1.2005
Time: 14:44:00
User: N/A
Computer: WDN
Description:
Service Apache2 was terminated with specific error 1.
I have reduced the code into two files, but I'm sorry I have no time to
create minimal test case. One file is a lib with 450 lines, second just
creates the object and calls the methods.
The bug appears when I do certain wild operations with tree made of
arrays of objects.
I know which block of code to comment out to get it work.
Also I have found the line where it crashes, although it tells nothing
(to me):
if($oTreeSub->sTag == 'text'){
Reproduce code:
---
I can not put the files here publicly because of security reasons, but
I can send them to someone who will shorten it to the bug's core and
put it here.
Please contact me at
ondra x dynawest. cz
zizka x seznam. cz
http://ondra.zizka.cz
Expected result:
Not to crash :)
Actual result:
--
Crashes.
And at last, I would like to bring attention to my feat.req. ->
http://bugs.php.net/bug.php?id=30228 . The answer is insufficient, I
would really like to know the reason why PHP4 cant run along with PHP5
on a single apache, or, more specifically, why PHP team does not want
it to. Please put there some link to that "forums", thanks.
--
Edit this bug report at http://bugs.php.net/?id=31765&edit=1
#31765 [Fbk->Opn]: PHP crashes when executing certain code
ID: 31765
User updated by: zizka at seznam dot cz
Reported By: zizka at seznam dot cz
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: All
PHP Version: 4.3.10
New Comment:
Here is the code reduced to 30 lines. It still crashes PHP module, but
I haven't tested it on other platforms. But I suppose the nature of the
bug is the same so it would crash everywhere again.
http://paste.phpfi.com/49791
Previous Comments:
[2005-01-31 19:36:20] [EMAIL PROTECTED]
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Please supply a SHORT 10-20 line script that can be used to replicate
the problem.
[2005-01-31 14:19:03] ondra at dynawest dot cz
Don't use zizka at seznam. cz - it doesn't work properly... Use ondra
ta dynawest. cz
[2005-01-30 18:42:24] zizka at seznam dot cz
Description:
PHP crashes on my code.
Reproduced on:
Windows 2000 / Apache 1.3.29 / PHP 4.3.6 (Apache mod)
Windows 2000 / Apache 1.3.29 / PHP 4.3.10 (Apache mod)
Windows 2000 / Apache 2.0.52 / PHP 4.3.10 (Apache mod)
Linux hercules 2.4.25 / Apache 1.3.33 / PHP 4.3.10 (Apache mod)
Windows NT 5.2 / Microsoft-IIS 6.0 / PHP Version 4.3.1 (CGI)
Windows 2000's report (transl. from Czech):
Event type: Chyba
Event source: Service Control Manager
Kategorie události: Není k dispozici
Event ID: 7024
Date: 29.1.2005
Time: 14:44:00
User: N/A
Computer: WDN
Description:
Service Apache2 was terminated with specific error 1.
I have reduced the code into two files, but I'm sorry I have no time to
create minimal test case. One file is a lib with 450 lines, second just
creates the object and calls the methods.
The bug appears when I do certain wild operations with tree made of
arrays of objects.
I know which block of code to comment out to get it work.
Also I have found the line where it crashes, although it tells nothing
(to me):
if($oTreeSub->sTag == 'text'){
Reproduce code:
---
I can not put the files here publicly because of security reasons, but
I can send them to someone who will shorten it to the bug's core and
put it here.
Please contact me at
ondra x dynawest. cz
zizka x seznam. cz
http://ondra.zizka.cz
Expected result:
Not to crash :)
Actual result:
--
Crashes.
And at last, I would like to bring attention to my feat.req. ->
http://bugs.php.net/bug.php?id=30228 . The answer is insufficient, I
would really like to know the reason why PHP4 cant run along with PHP5
on a single apache, or, more specifically, why PHP team does not want
it to. Please put there some link to that "forums", thanks.
--
Edit this bug report at http://bugs.php.net/?id=31765&edit=1
#31765 [NEW]: PHP crashes when executing certain code
From: zizka at seznam dot cz
Operating system: All
PHP version: 4.3.10
PHP Bug Type: Reproducible crash
Bug description: PHP crashes when executing certain code
Description:
PHP crashes on my code.
Reproduced on:
Windows 2000 / Apache 1.3.29 / PHP 4.3.6 (Apache mod)
Windows 2000 / Apache 1.3.29 / PHP 4.3.10 (Apache mod)
Windows 2000 / Apache 2.0.52 / PHP 4.3.10 (Apache mod)
Linux hercules 2.4.25 / Apache 1.3.33 / PHP 4.3.10 (Apache mod)
Windows NT 5.2 / Microsoft-IIS 6.0 / PHP Version 4.3.1 (CGI)
Windows 2000's report (transl. from Czech):
Event type: Chyba
Event source: Service Control Manager
Kategorie události: Není k dispozici
Event ID: 7024
Date: 29.1.2005
Time: 14:44:00
User: N/A
Computer: WDN
Description:
Service Apache2 was terminated with specific error 1.
I have reduced the code into two files, but I'm sorry I have no time to
create minimal test case. One file is a lib with 450 lines, second just
creates the object and calls the methods.
The bug appears when I do certain wild operations with tree made of arrays
of objects.
I know which block of code to comment out to get it work.
Also I have found the line where it crashes, although it tells nothing (to
me):
if($oTreeSub->sTag == 'text'){
Reproduce code:
---
I can not put the files here publicly because of security reasons, but I
can send them to someone who will shorten it to the bug's core and put it
here.
Please contact me at
ondra x dynawest. cz
zizka x seznam. cz
http://ondra.zizka.cz
Expected result:
Not to crash :)
Actual result:
--
Crashes.
And at last, I would like to bring attention to my feat.req. ->
http://bugs.php.net/bug.php?id=30228 . The answer is insufficient, I would
really like to know the reason why PHP4 cant run along with PHP5 on a
single apache, or, more specifically, why PHP team does not want it to.
Please put there some link to that "forums", thanks.
--
Edit bug report at http://bugs.php.net/?id=31765&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31765&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31765&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31765&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31765&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31765&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31765&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31765&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31765&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31765&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31765&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31765&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31765&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31765&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31765&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31765&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31765&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31765&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31765&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31765&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31765&r=mysqlcfg
#31659 [NEW]: array_map to take non-array parameters and pass them to the callback function
From: zizka at seznam dot cz
Operating system:
PHP version: 5.0.1
PHP Bug Type: Feature/Change Request
Bug description: array_map to take non-array parameters and pass them to the
callback function
Description:
array_map could take non-array parameters and pass them to the callback
function in each step.
Example:
$a = explode(' ', 'XyX aXb sXs');
$a = array_map('str_replace', 'X','Y', $a);
That would result in calling:
str_replace('X','Y', $a[...]);
and the result array would be like
Array('YyY', 'aYb', 'sYs');
Now I have to define a callback function for many simple operations that
could be done this way.
Thanks, Ondra Zizka
Reproduce code:
---
$a = explode(' ', 'XyX aXb sXs');
$a = array_map('str_replace', 'X','Y', $a);
print_r($a);
Expected result:
Array([0] => YyY[1] => aYb[2] => sYs)
Actual result:
--
Warning: array_map() [function.array-map.htm]: Argument #2 should be an
array in ...
--
Edit bug report at http://bugs.php.net/?id=31659&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31659&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31659&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31659&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31659&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31659&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31659&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31659&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31659&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31659&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31659&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31659&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31659&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31659&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31659&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31659&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31659&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31659&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31659&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31659&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31659&r=mysqlcfg
#30228 [WFx]: PHP5 and PHP4 run together on a single Apache virtual server
ID: 30228 User updated by: zizka at seznam dot cz Reported By: zizka at seznam dot cz Status: Wont fix Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5.0.1 New Comment: It's bad when somebody spams this page, but it's also bad not to answer correctly. Please tell me about some concrete mailing list thread. I've tried to find, but didn't find anything (don't ask why :) . Previous Comments: [2004-10-01 21:27:11] [EMAIL PROTECTED] Won't happen, don't ask why. (you can try reading the mailing list archives..) -------- [2004-09-25 01:38:03] zizka at seznam dot cz Description: I need to have PHP4 and PHP5 running together on a single Apache virtual server as SAPI modules. Don't ask why. With every new PHP's main version (4,5) it becomes harder to have the new version running with the old one. I use .php3, .php4, and .php5 exts; .php is for my currently favorite version. Since the PHP3 had "application/x-httpd-php3" as the Action handler, setting application/x-httpd-php for PHP4 was not a problem. But as PHP5 uses the same, it's quite difficult. I changed this string in the php5apache.dll file and configured Apache 1.3: # PHP 4 LoadModule php4_module "c:/program files/php436/sapi/php4apache.dll" AddType application/x-httpd-php .php AddType application/x-httpd-php .php4 # PHP 5 LoadModule php5_module "c:/program files/php5/php5apache.dll" AddType application/x-httpd-ph5 .php5 SetEnv PHPRC "c:/php.ini" This works, but the problem is with php.ini. PHP seems not to be willing to load it from anywhere else than WINNT directory. I tried every way documented, but only one works, and only for PHP5: * PHPIniDir directive (Apache 2 module only) -- I need Apache 1.3 * HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath -- Works for PHP5 only * Apache's SetEnv PHPRC "c:/" -- Doesn't work at all, I tried \ and \\ too * The PHPRC environment variable -- Doesn't work at all * PHP's dir (for CLI) or server's dir (SAPI) -- I need to set different for 4 and 5 * Windows directory (C:\windows or C:\winnt) -- I need to set different for 4 and 5 There's also one bug - the first request to PHP version, other than the server's first PHP request used, keeps hanging until the server shutdown. Further are ok. Reproduce code: --- The Apache's conf is above. Expected result: I would like this to be done: First, update the documentation to reflect the real state of things; I mean the php.ini location process. Second, don't unify the important strings like Apache Action name (application/x-httpd-php) and env vars (like PHPRC). Instead, use different for every main version number (application/x-httpd-php5, PHP5_RC). Third, do it generally more possible to have concurent versions running on the same virtual server. -- Edit this bug report at http://bugs.php.net/?id=30228&edit=1
#30228 [NEW]: PHP5 and PHP4 run together on a single Apache virtual server
From: zizka at seznam dot cz Operating system: Windows 2000 PHP version: 5.0.1 PHP Bug Type: *Configuration Issues Bug description: PHP5 and PHP4 run together on a single Apache virtual server Description: I need to have PHP4 and PHP5 running together on a single Apache virtual server as SAPI modules. Don't ask why. With every new PHP's main version (4,5) it becomes harder to have the new version running with the old one. I use .php3, .php4, and .php5 exts; .php is for my currently favorite version. Since the PHP3 had "application/x-httpd-php3" as the Action handler, setting application/x-httpd-php for PHP4 was not a problem. But as PHP5 uses the same, it's quite difficult. I changed this string in the php5apache.dll file and configured Apache 1.3: # PHP 4 LoadModule php4_module "c:/program files/php436/sapi/php4apache.dll" AddType application/x-httpd-php .php AddType application/x-httpd-php .php4 # PHP 5 LoadModule php5_module "c:/program files/php5/php5apache.dll" AddType application/x-httpd-ph5 .php5 SetEnv PHPRC "c:/php.ini" This works, but the problem is with php.ini. PHP seems not to be willing to load it from anywhere else than WINNT directory. I tried every way documented, but only one works, and only for PHP5: * PHPIniDir directive (Apache 2 module only) -- I need Apache 1.3 * HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath -- Works for PHP5 only * Apache's SetEnv PHPRC "c:/" -- Doesn't work at all, I tried \ and \\ too * The PHPRC environment variable -- Doesn't work at all * PHP's dir (for CLI) or server's dir (SAPI) -- I need to set different for 4 and 5 * Windows directory (C:\windows or C:\winnt) -- I need to set different for 4 and 5 There's also one bug - the first request to PHP version, other than the server's first PHP request used, keeps hanging until the server shutdown. Further are ok. Reproduce code: --- The Apache's conf is above. Expected result: I would like this to be done: First, update the documentation to reflect the real state of things; I mean the php.ini location process. Second, don't unify the important strings like Apache Action name (application/x-httpd-php) and env vars (like PHPRC). Instead, use different for every main version number (application/x-httpd-php5, PHP5_RC). Third, do it generally more possible to have concurent versions running on the same virtual server. -- Edit bug report at http://bugs.php.net/?id=30228&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30228&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30228&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30228&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30228&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30228&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30228&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30228&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30228&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30228&r=support Expected behavior: http://bugs.php.net/fix.php?id=30228&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30228&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30228&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30228&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30228&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30228&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30228&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30228&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30228&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30228&r=mysqlcfg
#21891 [Com]: Closing PHP tag and Newlines Revisted
ID: 21891 Comment by: zizka at seznam dot cz Reported By: hz11 at nyu dot edu Status: Wont fix Bug Type: Feature/Change Request Operating System: FreeBSD/Linux PHP Version: 4.3.0 New Comment: Sorry but still I don't understand, why some new option in php.ini "would make writing portable scripts harder", if the default option would make PHP behave the SAME way as so far, that means (in this case), removing (\r)\n after ?>, and the second option would make it leave it there. Or, if it's really true, why have we the options like arg_separator.input and magic_quotes_gpc then? What's so hard in writing portable scripts like now and leaving this option with the default falue, while other people, using PHP for e.g. nice-formatted HTML, C++ code, ASCII, or XML, would change it? ... Doesn't make a sense... Previous Comments: [2004-03-10 12:21:35] [EMAIL PROTECTED] Making a setting in php.ini would make writing portable scripts harder, so that's a no-go too. -------- [2004-03-10 11:48:37] zizka at seznam dot cz Heeyyy!!! Wake UP! It wouldn't break ANY script if it was optional in the php.ini file As I wrote to derick: Are the PHP developers getting too lazy to improve PHP a bit? [2004-03-10 10:56:45] hz11 at nyu dot edu How would it break existing scripts? Firstly, CLI scripts aren't that common yet, and especially those that rely on this type of behavior. Secondly, what if it was a config setting, available only when running as a CLI (akin to argv/argc). When working with scripts on the console for interactive programs, or using a CLI script to generate raw XML for instance, this type of newline mangle makes no sense and is cause for very hackish scripts. [2004-03-08 12:03:42] [EMAIL PROTECTED] Can not be fixed, as it breaks existing scripts. [2004-03-08 11:29:38] hz11 at nyu dot edu I agree. Now that the CLI interface has matured it's in fairly widespread use. I use CLI continually and this "feature" is a royal pain. Perhaps when running in CLI mode this behavior could be automatically disabled... this would be a much appreciated change. Or, a special tag as suggested: http://bugs.php.net/21891 -- Edit this bug report at http://bugs.php.net/?id=21891&edit=1
#27549 [Bgs]: Removing whitespace after closing tag should be optional
ID: 27549 User updated by: zizka at seznam dot cz Reported By: zizka at seznam dot cz Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.4 New Comment: It wouldn't break ANY script if it was optional in the php.ini file. Are the Zend developers getting too lazy to improve their engine a bit? This feature, actually an intended bug, makes a lot of people mad. Tell me why shouln't it have a directive in php.ini like closing_tag_trimmed = On | Off , On by default ??? Previous Comments: [2004-03-10 09:26:44] [EMAIL PROTECTED] Already filed, and already declined. [2004-03-10 09:19:29] zizka at seznam dot cz Description: Removing whitespace after closing tag is quite annoying and should be optional. Every webmaster looks into the page code to see what's the problem, and when he drops out of PHP parsing mode with ?> instead of echo()ing, the resulting code is quite awful: Without this feature, the output would be like this: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better But, because of it, instead of such nice code we get: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better I could come up with better examples, but they would be too complex. But believe me, sometimes I get a line > 2000 characters long! (And adding echo "\n"; is out of question.) Thx -- Edit this bug report at http://bugs.php.net/?id=27549&edit=1
#21891 [Com]: Closing PHP tag and Newlines Revisted
ID: 21891 Comment by: zizka at seznam dot cz Reported By: hz11 at nyu dot edu Status: Wont fix Bug Type: Feature/Change Request Operating System: FreeBSD/Linux PHP Version: 4.3.0 New Comment: Heeyyy!!! Wake UP! It wouldn't break ANY script if it was optional in the php.ini file As I wrote to derick: Are the PHP developers getting too lazy to improve PHP a bit? Previous Comments: [2004-03-10 10:56:45] hz11 at nyu dot edu How would it break existing scripts? Firstly, CLI scripts aren't that common yet, and especially those that rely on this type of behavior. Secondly, what if it was a config setting, available only when running as a CLI (akin to argv/argc). When working with scripts on the console for interactive programs, or using a CLI script to generate raw XML for instance, this type of newline mangle makes no sense and is cause for very hackish scripts. [2004-03-08 12:03:42] [EMAIL PROTECTED] Can not be fixed, as it breaks existing scripts. [2004-03-08 11:29:38] hz11 at nyu dot edu I agree. Now that the CLI interface has matured it's in fairly widespread use. I use CLI continually and this "feature" is a royal pain. Perhaps when running in CLI mode this behavior could be automatically disabled... this would be a much appreciated change. Or, a special tag as suggested: or something?). That way it would still be backwards-compatible. [2003-05-20 15:34:06] csnyder at chxo dot com "Included files shouldn't even contain a closing tag, for these exact reasons." This is excellent advice, but it is *not* a documented practice. All of the examples in the Basic Syntax documentation include closing tags. In fact, the documentation for include() says: "... any code inside the target file which should be executed as PHP code must be enclosed within valid PHP start and end tags." I agree wholeheartedly that both the documentation and the behavior should be changed, but to do so is to risk breaking a lot of existing 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 http://bugs.php.net/21891 -- Edit this bug report at http://bugs.php.net/?id=21891&edit=1
#27549 [NEW]: Removing whitespace after closing tag should be optional
From: zizka at seznam dot cz Operating system: All PHP version: 4.3.4 PHP Bug Type: Feature/Change Request Bug description: Removing whitespace after closing tag should be optional Description: Removing whitespace after closing tag is quite annoying and should be optional. Every webmaster looks into the page code to see what's the problem, and when he drops out of PHP parsing mode with ?> instead of echo()ing, the resulting code is quite awful: Without this feature, the output would be like this: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better But, because of it, instead of such nice code we get: About PHP PHP's quite good thing, but still can be better About PHP PHP's quite good thing, but still can be better I could come up with better examples, but they would be too complex. But believe me, sometimes I get a line > 2000 characters long! (And adding echo "\n"; is out of question.) Thx -- Edit bug report at http://bugs.php.net/?id=27549&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27549&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27549&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27549&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27549&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27549&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27549&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27549&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27549&r=support Expected behavior: http://bugs.php.net/fix.php?id=27549&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27549&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27549&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27549&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27549&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27549&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27549&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27549&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27549&r=float
