#47475 [NEW]: Propose to add curl_multi_timeout() to curl_multi_select(..., 0)
From: php at koterov dot ru
Operating system: all
PHP version: 5.2.9RC3
PHP Bug Type: cURL related
Bug description: Propose to add curl_multi_timeout() to curl_multi_select(...,
0)
Description:
I propose to add the following simple modification to curl_multi_select()
function. Now it is greatly miss the functionality to detect the timeout
automatically.
ext\curl\multi.c:
...
PHP_FUNCTION(curl_multi_select)
{
zval *z_mh;
php_curlm *mh;
fd_set readfds;
fd_set writefds;
fd_set exceptfds;
int maxfd;
double timeout = 1.0;
struct timeval to;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "r|d", &z_mh,
&timeout) == FAILURE) {
return;
}
ZEND_FETCH_RESOURCE(mh, php_curlm *, &z_mh, -1,
le_curl_multi_handle_name, le_curl_multi_handle);
_make_timeval_struct(&to, timeout);
+
+ /* If timeout == 0 is passed, detect it automatically. */
+ if (!to.tv_sec && !to.tv_usec) {
+ long max_tout = 1000;
+ if ((CURLM_OK == curl_multi_timeout(mh->multi, &max_tout)) &&
(max_tout
!= -1)) {
+ to->tv_sec = max_tout / 1000;
+ to->tv_usec = (max_tout % 1000) * 1000;
+ }
+ }
+
FD_ZERO(&readfds);
FD_ZERO(&writefds);
FD_ZERO(&exceptfds);
curl_multi_fdset(mh->multi, &readfds, &writefds, &exceptfds, &maxfd);
RETURN_LONG(select(maxfd + 1, &readfds, &writefds, &exceptfds, &to));
}
Reproduce code:
---
cURL has built-in ability to detect the minimal delay till a next handle
timeout in the pool. But there is no chance to use this feature in PHP,
because there is no such function. So we have to perform busy wait loops.
Expected result:
curl_multi_select($h, 0)
waits till the next request timeout at most.
Actual result:
--
there is no chance to catch a handle timeout without busy-wait loop now.
--
Edit bug report at http://bugs.php.net/?id=47475&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47475&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47475&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47475&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47475&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47475&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47475&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47475&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47475&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47475&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47475&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47475&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47475&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47475&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47475&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47475&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47475&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47475&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47475&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47475&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47475&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47475&r=mysqlcfg
#47269 [NEW]: Typo: SoapSlient instead of SoapClient
From: php at koterov dot ru Operating system: all PHP version: 5.2.8 PHP Bug Type: SOAP related Bug description: Typo: SoapSlient instead of SoapClient Description: In various extension error messages, e.g. Uncaught SoapFault exception: [Client] SoapSlient::__doRequest() returned non string value You see, "SoapSlient" instead of "SoapClient". If you search by "SoapSlient" over the extension source code, you will find all matches. -- Edit bug report at http://bugs.php.net/?id=47269&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47269&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47269&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47269&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47269&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47269&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47269&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47269&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47269&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47269&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47269&r=support Expected behavior: http://bugs.php.net/fix.php?id=47269&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47269&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47269&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47269&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47269&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47269&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47269&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47269&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47269&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47269&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47269&r=mysqlcfg
#45111 [Opn]: Support of #line instruction for parser context substitutuon
ID: 45111 User updated by: php at koterov dot ru Reported By: php at koterov dot ru Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 5.2.6 New Comment: I have dug the PHP source code a little. Hmm, seems this feature is not too easy to implement... Line number is stored in znode, it's easy to substitute. But filename is stored in zend_op_array, NOT in zend_op. So, for a sequence of opcodes grouped by a single zend_op_array there is no chance to specify different filenames. (Of course I could add a field to zend_op, but in this case all accelerators like eAccelerator seem to stop working, because they know nothing about this field and do not store/restore it.) Am I right? Previous Comments: [2008-05-27 22:54:09] php at koterov dot ru Description: In Perl, we could write the following program test.pl (lines are enumerated for better look): 01 #!/usr/bin/perl -w 02 print "hello!\n"; 03 print "something!\n"; 04 05 #line 100 "aaa.pl" 06 print $undefined_var; This code generates a warning message "Using of undefined variable", but (attention!) - the context of this error is NOT "test.pl line 5", but - "aaa.pl line 100". So, the "pseudo-comment" operator #line xxx "yyy" in Perl substitutes the current parsing context to a specified line number and filename. (You may ommit filename, then - only the line number will be substituted). And, if a warning or a fatal error occurs, the line number and filename in the error message will be changed. There is the same feature in C language: it is used by C preprocessor to execute #include directives an keep line numbers clear to understand. This feature is VERY VERY useful when we write some code translator (e.g. from a templating language to pure PHP). This kind of translation is done e.g. in Smarty: it translates Smarty templates into pure PHP code, but line numbers are mixed up in translated files, so we cannot revert back and detect which line of the template had produced an error. Please say, do you plan to add this feature to a new PHP versions? I'd like to ask you very much about it... -- Edit this bug report at http://bugs.php.net/?id=45111&edit=1
#45111 [NEW]: Support of #line instruction for parser context substitutuon
From: php at koterov dot ru Operating system: all PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: Support of #line instruction for parser context substitutuon Description: In Perl, we could write the following program test.pl (lines are enumerated for better look): 01 #!/usr/bin/perl -w 02 print "hello!\n"; 03 print "something!\n"; 04 05 #line 100 "aaa.pl" 06 print $undefined_var; This code generates a warning message "Using of undefined variable", but (attention!) - the context of this error is NOT "test.pl line 5", but - "aaa.pl line 100". So, the "pseudo-comment" operator #line xxx "yyy" in Perl substitutes the current parsing context to a specified line number and filename. (You may ommit filename, then - only the line number will be substituted). And, if a warning or a fatal error occurs, the line number and filename in the error message will be changed. There is the same feature in C language: it is used by C preprocessor to execute #include directives an keep line numbers clear to understand. This feature is VERY VERY useful when we write some code translator (e.g. from a templating language to pure PHP). This kind of translation is done e.g. in Smarty: it translates Smarty templates into pure PHP code, but line numbers are mixed up in translated files, so we cannot revert back and detect which line of the template had produced an error. Please say, do you plan to add this feature to a new PHP versions? I'd like to ask you very much about it... -- Edit bug report at http://bugs.php.net/?id=45111&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45111&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45111&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45111&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45111&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45111&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45111&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45111&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45111&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45111&r=support Expected behavior:http://bugs.php.net/fix.php?id=45111&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45111&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45111&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45111&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45111&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45111&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45111&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45111&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45111&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45111&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45111&r=mysqlcfg
#43411 [NEW]: parse_url with relative URLs contained http:// in parameters
From: php at koterov dot ru
Operating system:
PHP version: 5.2.5
PHP Bug Type: URL related
Bug description: parse_url with relative URLs contained http:// in parameters
Description:
When I pass a relative URL to parse_url and it contains something like
"http://xxx"; in QUERY_STRING parameters, parse_url reports that the URL is
broken.
So it is not always safe to call
parse_url($_SERVER['REQUEST_URI'])
I think the solution should be: if an URL is relative (started with '/'),
do not report a warning when its arguments contain ":".
Possibly you will say "won't fix" and "URL is not RFC-complaint", but this
argument is not relevant when I call parse_url($_SERVER['REQUEST_URI']) (it
may be hand-made and non-RFC complaint).
Reproduce code:
---
print_r(parse_url('/test/?retpath=http://xxx'));
Expected result:
ok
Actual result:
--
Warning: parse_url(/test/?retpath=http://xxx): Unable to parse URL
--
Edit bug report at http://bugs.php.net/?id=43411&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43411&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43411&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43411&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43411&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43411&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43411&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43411&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43411&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43411&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43411&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43411&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43411&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43411&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43411&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43411&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43411&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43411&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43411&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43411&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43411&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43411&r=mysqlcfg
#41607 [NEW]: Unexpected Memcache::get(): marked server ... as failed
From: php at koterov dot ru Operating system: Linux PHP version: 5.2.3 PHP Bug Type: Unknown/Other Function Bug description: Unexpected Memcache::get(): marked server ... as failed Description: On heavy loaded server (20-40 requests/s) I periodically (0nce a second) get an error message from memcached extension: # tail -f php-error_log |grep failed PHP Notice: Memcache::get(): marked server '127.0.0.1:11211' as failed ... But the server is up, the maximum number of connections (-m 1024) is not reached. And this error does not depend on how long the memcached server is running: a couple of minutes after memcached restart I can watch the same error, the statistics is: stats STAT pid 19854 STAT uptime 337 STAT time 1181115051 STAT version 1.2.2 STAT pointer_size 64 STAT rusage_user 1.727737 STAT rusage_system 6.867955 STAT curr_items 63413 STAT total_items 64222 STAT bytes 114838739 STAT curr_connections 16 STAT total_connections 3888 STAT connection_structures 27 STAT cmd_get 259618 STAT cmd_set 64563 STAT get_hits 196161 STAT get_misses 63457 STAT evictions 0 STAT bytes_read 148496793 STAT bytes_written 394115419 STAT limit_maxbytes 1073741824 STAT threads 1 I tried to disable setCompressThreshold, increase memcache.chunk_size, disable persistent connections, enlarge timeout parameters, but an error still happens. Furthermore, this error happens on Windows more frequently, even without heavy load, but I cannot reproduce. I have the only memcached server added: $this->connection = new Memcache(); $this->connection->addServer( "localhost", 11211, true, 1, 10, 2 ); -- Edit bug report at http://bugs.php.net/?id=41607&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41607&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41607&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41607&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41607&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41607&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41607&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41607&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41607&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41607&r=support Expected behavior:http://bugs.php.net/fix.php?id=41607&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41607&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41607&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41607&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41607&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41607&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41607&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41607&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41607&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41607&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41607&r=mysqlcfg
#40506 [Bgs->Opn]: comment
ID: 40506
User updated by: php at koterov dot ru
-Summary: Suggestion: json_encode() and non-UTF8 strings
Reported By: php at koterov dot ru
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.2.1
New Comment:
I understand that JSON is UTF8-based format. But the question was
different: why json_encode() wastes CPU time for analyze the input data
instead of passing it through?
And the second thought. Assume that the output of json_encode must be
UTF8, OK. But why should it limit us to use UTF8 as its input
parameter? Ideologically input != output.
The main disadvantage that I cannot iterate through all of the input
data and call iconv() for it before passing the resulting array to
json_encode(). Because it is very CPU expensive (e.g. if I transfer
more than 500 strings, each about 30 characters length, the slowdown is
great).
Theoretically json_encode() is irreplaceable for fast execution and CPU
saving only, but it is totally impossible in non-UTF8 sites. Because of
the speed is not needed, it is very easy to use PHP version of this
function.
I think that if we want to follow the RFC literally, it may be better
to write json_encode() without any encoding analyzation, and after that
- call iconv() ONE TIME to convert the resulting string to UTF8. It is
much more faster than calling of iconv() for each input string. Maybe -
pass the second optional parameter, $src_encoding, to json_encode() to
specify input encoding.
Previous Comments:
[2007-02-17 15:50:14] [EMAIL PROTECTED]
http://www.ietf.org/rfc/rfc4627.txt?number=4627
see section 3
[2007-02-16 10:47:31] php at koterov dot ru
Description:
Could you please explain why json_encode() takes care about the
encoding at all? Why not to treat all the string data as a binary flow?
This is very inconvenient and disallows the usage of json_encode() in
non-UTF8 sites! :-(
I have written a small substitution for json_encode(), but note that it
of course works much more slow than json_encode() with big data
arrays..
/**
* Convert PHP scalar, array or hash to JS scalar/array/hash.
*/
function php2js($a)
{
if (is_null($a)) return 'null';
if ($a === false) return 'false';
if ($a === true) return 'true';
if (is_scalar($a)) {
$a = addslashes($a);
$a = str_replace("\n", '\n', $a);
$a = str_replace("\r", '\r', $a);
$a = preg_replace('{($v)
$result[] = php2js($k) . ': ' . php2js($v);
return '{ ' . join(', ', $result) . ' }';
}
}
So, my suggestion is remove all string analyzation from json_encode()
code. It also make this function to work faster.
Reproduce code:
---
'проверка', 'b' =>
array('слуха',
'глухого'));
echo json_encode($a);
?>
Expected result:
Correctly encoded string in the source 1-byte encoding.
Actual result:
--
Empty strings everywhere (and sometimes - notices that a string
contains non-UTF8 characters).
--
Edit this bug report at http://bugs.php.net/?id=40506&edit=1
#40506 [NEW]: Suggestion: json_encode() and non-UTF8 strings
From: php at koterov dot ru
Operating system: all
PHP version: 5.2.1
PHP Bug Type: Unknown/Other Function
Bug description: Suggestion: json_encode() and non-UTF8 strings
Description:
Could you please explain why json_encode() takes care about the encoding
at all? Why not to treat all the string data as a binary flow? This is
very inconvenient and disallows the usage of json_encode() in non-UTF8
sites! :-(
I have written a small substitution for json_encode(), but note that it of
course works much more slow than json_encode() with big data arrays..
/**
* Convert PHP scalar, array or hash to JS scalar/array/hash.
*/
function php2js($a)
{
if (is_null($a)) return 'null';
if ($a === false) return 'false';
if ($a === true) return 'true';
if (is_scalar($a)) {
$a = addslashes($a);
$a = str_replace("\n", '\n', $a);
$a = str_replace("\r", '\r', $a);
$a = preg_replace('{($v)
$result[] = php2js($k) . ': ' . php2js($v);
return '{ ' . join(', ', $result) . ' }';
}
}
So, my suggestion is remove all string analyzation from json_encode()
code. It also make this function to work faster.
Reproduce code:
---
'проверка', 'b' =>
array('слуха',
'глухого'));
echo json_encode($a);
?>
Expected result:
Correctly encoded string in the source 1-byte encoding.
Actual result:
--
Empty strings everywhere (and sometimes - notices that a string contains
non-UTF8 characters).
--
Edit bug report at http://bugs.php.net/?id=40506&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40506&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40506&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40506&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40506&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40506&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40506&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40506&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40506&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40506&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40506&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40506&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40506&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40506&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40506&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40506&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40506&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40506&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40506&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40506&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40506&r=mysqlcfg
#40004 [Opn]: preg_match() with /u flag corrupts memory
ID: 40004 User updated by: php at koterov dot ru Reported By: php at koterov dot ru Status: Open Bug Type: PCRE related Operating System: Windows XP PHP Version: 4.4.4 New Comment: This is also reproducible in command-line php.exe PHP 4.4.4 PHP 5.1.6 (!) Cannot reproduce on PHP 5.2.0. Previous Comments: [2007-01-03 00:10:57] php at koterov dot ru Description: Seems preg_match with /u modifier corrupts process memory or returns pointer to nirvana instead of pointer to a string. Reproduce code: --- Expected result: space Actual result: -- something like array ( 0 => ' kjwekwjn', 1 => ' wereinoiu', ) where "kjwekwjn" and "wereinoiu" are random strings with random binary data (useless to copy-paste them here). -- Edit this bug report at http://bugs.php.net/?id=40004&edit=1
#40004 [NEW]: preg_match() with /u flag corrupts memory
From: php at koterov dot ru Operating system: Windows XP PHP version: 4.4.4 PHP Bug Type: PCRE related Bug description: preg_match() with /u flag corrupts memory Description: Seems preg_match with /u modifier corrupts process memory or returns pointer to nirvana instead of pointer to a string. Reproduce code: --- Expected result: space Actual result: -- something like array ( 0 => ' kjwekwjn', 1 => ' wereinoiu', ) where "kjwekwjn" and "wereinoiu" are random strings with random binary data (useless to copy-paste them here). -- Edit bug report at http://bugs.php.net/?id=40004&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40004&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40004&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40004&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40004&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40004&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40004&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40004&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40004&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40004&r=support Expected behavior:http://bugs.php.net/fix.php?id=40004&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40004&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40004&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40004&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40004&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40004&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40004&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40004&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40004&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40004&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40004&r=mysqlcfg
#39138 [Fbk->Opn]: LOCK_NB for flock() does not work
ID: 39138 User updated by: php at koterov dot ru Reported By: php at koterov dot ru -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows, Linux PHP Version: 5.1.6 New Comment: I cannot try snapshot on Linux - I have no machine for experiments. And you said that Linux has no problem in new version. Now we are talking about Windows only. Previous Comments: [2006-10-13 14:20:28] [EMAIL PROTECTED] Wait, so did you try the snapshot on Linux? Or are you talking only of Windows now? [2006-10-13 14:12:58] php at koterov dot ru Thanks for detailed testing. Server version: Apache/2.0.54 Server built: Apr 16 2005 14:25:31 Windows XP, NTFS. I don't know if my server threaded or not; where could I see that? With command-line php.exe effect is NOT quite reproducible: first process prints "bool(true) int(0)", second - "bool(false) int(0)". (Note that in both cases we have 0 in $w; is it proper or not?) One time I've got in additional a message: "Failed to start up concurrent users module!" with php.exe, but cannot reproduce this message again now. [2006-10-13 13:43:17] [EMAIL PROTECTED] What kind of Server API do you use and is your web-server threaded or not? Where can I see the results? (as I'm unable to reproduce it locally) -------------------- [2006-10-13 13:38:31] php at koterov dot ru PHP 5.2.0RC6-dev (cli) (built: Oct 13 2006 12:22:44) Bug is reproducible. [2006-10-13 08:34:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip 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/39138 -- Edit this bug report at http://bugs.php.net/?id=39138&edit=1
#39138 [Fbk->Opn]: LOCK_NB for flock() does not work
ID: 39138 User updated by: php at koterov dot ru Reported By: php at koterov dot ru -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows, Linux PHP Version: 5.1.6 New Comment: Thanks for detailed testing. Server version: Apache/2.0.54 Server built: Apr 16 2005 14:25:31 Windows XP, NTFS. I don't know if my server threaded or not; where could I see that? With command-line php.exe effect is NOT quite reproducible: first process prints "bool(true) int(0)", second - "bool(false) int(0)". (Note that in both cases we have 0 in $w; is it proper or not?) One time I've got in additional a message: "Failed to start up concurrent users module!" with php.exe, but cannot reproduce this message again now. Previous Comments: [2006-10-13 13:43:17] [EMAIL PROTECTED] What kind of Server API do you use and is your web-server threaded or not? Where can I see the results? (as I'm unable to reproduce it locally) -------------------- [2006-10-13 13:38:31] php at koterov dot ru PHP 5.2.0RC6-dev (cli) (built: Oct 13 2006 12:22:44) Bug is reproducible. [2006-10-13 08:34:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip -------------------- [2006-10-13 06:47:58] php at koterov dot ru Ah, on Linux bug is reproducible at version 5.1.1. Sorry, I do not have more recent test machine. On Windows - I've tested 5.1.6, bug is reproducible. [2006-10-12 14:44:12] [EMAIL PROTECTED] Not reproducible on Linux. 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/39138 -- Edit this bug report at http://bugs.php.net/?id=39138&edit=1
#39138 [Fbk->Opn]: LOCK_NB for flock() does not work
ID: 39138 User updated by: php at koterov dot ru Reported By: php at koterov dot ru -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows, Linux PHP Version: 5.1.6 New Comment: PHP 5.2.0RC6-dev (cli) (built: Oct 13 2006 12:22:44) Bug is reproducible. Previous Comments: [2006-10-13 08:34:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-10-13 06:47:58] php at koterov dot ru Ah, on Linux bug is reproducible at version 5.1.1. Sorry, I do not have more recent test machine. On Windows - I've tested 5.1.6, bug is reproducible. [2006-10-12 14:44:12] [EMAIL PROTECTED] Not reproducible on Linux. [2006-10-12 14:19:19] php at koterov dot ru Description: When I run this script concurrently, all results are same: "bool(true) int(0)". Seems LOCK_NB simply ignored. P.S. There is a lot of same bugs (e.g., http://bugs.php.net/bug.php?id=31363 etc.), but they are closed or outdated. -- Edit this bug report at http://bugs.php.net/?id=39138&edit=1
#39138 [Fbk->Opn]: LOCK_NB for flock() does not work
ID: 39138 User updated by: php at koterov dot ru Reported By: php at koterov dot ru -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows, Linux PHP Version: 5.1.6 New Comment: Ah, on Linux bug is reproducible at version 5.1.1. Sorry, I do not have more recent test machine. On Windows - I've tested 5.1.6, bug is reproducible. Previous Comments: [2006-10-12 14:44:12] [EMAIL PROTECTED] Not reproducible on Linux. [2006-10-12 14:19:19] php at koterov dot ru Description: When I run this script concurrently, all results are same: "bool(true) int(0)". Seems LOCK_NB simply ignored. P.S. There is a lot of same bugs (e.g., http://bugs.php.net/bug.php?id=31363 etc.), but they are closed or outdated. -- Edit this bug report at http://bugs.php.net/?id=39138&edit=1
#39138 [NEW]: LOCK_NB for flock() does not work
From: php at koterov dot ru Operating system: Windows, Linux PHP version: 5.1.6 PHP Bug Type: Filesystem function related Bug description: LOCK_NB for flock() does not work Description: When I run this script concurrently, all results are same: "bool(true) int(0)". Seems LOCK_NB simply ignored. P.S. There is a lot of same bugs (e.g., http://bugs.php.net/bug.php?id=31363 etc.), but they are closed or outdated. -- Edit bug report at http://bugs.php.net/?id=39138&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39138&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39138&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39138&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39138&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39138&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39138&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39138&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39138&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39138&r=support Expected behavior:http://bugs.php.net/fix.php?id=39138&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39138&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39138&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39138&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39138&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39138&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39138&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39138&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39138&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39138&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39138&r=mysqlcfg
#36051 [NEW]: Suspicous reference-argument behavour at func($m=null)
From: php at koterov dot ru Operating system: Windows XP PHP version: 5.1.2 PHP Bug Type: Scripting Engine problem Bug description: Suspicous reference-argument behavour at func($m=null) Description: Seems assignment-and-passing by reference becomes broken in PHP 5.1. PHP 4.x and 5.0 work as expected. See sample below. Seems PHP assigns value to $x AFTER calling function f(), but NOT before it. Or - only copy of $x passed to f(), not $x itself (as in 4.0 & 5.0). Reproduce code: --- Expected result: int(123) Actual result: -- int(0) -- Edit bug report at http://bugs.php.net/?id=36051&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36051&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36051&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36051&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36051&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36051&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36051&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36051&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36051&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36051&r=support Expected behavior:http://bugs.php.net/fix.php?id=36051&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36051&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36051&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36051&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36051&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36051&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36051&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36051&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36051&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36051&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36051&r=mysqlcfg
#36046 [NEW]: Bad line number in parse_ini_file error message
From: php at koterov dot ru Operating system: Windows XP PHP version: 5.1.2 PHP Bug Type: Filesystem function related Bug description: Bad line number in parse_ini_file error message Description: When using multiline INI values, line counter breaks. Seems parser always perceive one directive as one line. So, debugging becomes difficult where are errors in INI file (see example below, directive [other = aa " bb "] has syntax error. Reproduce code: --- -- t_pif_line.php -- -- t_pif_line.ini -- key = "aaa bbb ccc " other = aa " bb " Expected result: Warning: Error parsing t_pif_line.ini on line 5 in P:\home\localhost\www\t_pif_line.php on line 2 Actual result: -- Warning: Error parsing t_pif_line.ini on line 2 in P:\home\localhost\www\t_pif_line.php on line 2 -- Edit bug report at http://bugs.php.net/?id=36046&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36046&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36046&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36046&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36046&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36046&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36046&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36046&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36046&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36046&r=support Expected behavior:http://bugs.php.net/fix.php?id=36046&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36046&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36046&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36046&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36046&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36046&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36046&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36046&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36046&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36046&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36046&r=mysqlcfg
#36045 [NEW]: Nested quotes are ignored by parse_ini_file
From: php at koterov dot ru
Operating system: Windows XP
PHP version: 5.1.2
PHP Bug Type: Filesystem function related
Bug description: Nested quotes are ignored by parse_ini_file
Description:
While using parse_ini_file there is no possibility to insert double-quote
in the value. Seems function completely removes nested quotes and da data
between them.
Standard for INI file "quote quoting" method is doubling (see MS Excell,
Thunderbird, Outlook, GMail programs which could create INI files). But it
does not work with parse_ini_file.
Reproduce code:
---
--file.ini--
key = "test""quotes"
--test.php--
print_r(parse_ini_file('file.ini'));
Expected result:
test"quotes
Actual result:
--
testquotes
--
Edit bug report at http://bugs.php.net/?id=36045&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36045&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36045&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36045&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36045&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36045&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36045&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36045&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36045&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36045&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36045&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36045&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36045&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36045&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36045&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36045&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36045&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36045&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36045&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36045&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36045&r=mysqlcfg
#34695 [Opn->Bgs]: preg_replace(): {}-expresion overflow
ID: 34695
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 4.4.0
New Comment:
You are right:
> pcretest.exe
re> / ( (?: [^<] | < [^>]* >){1,1000}) .* /xs
Failed: regular expression too large at offset 0
Don't know why, but - this RE was not eaten by PCRE lib.
Sorry.
Previous Comments:
[2005-10-03 08:49:27] [EMAIL PROTECTED]
Perl doesn't use libpcre at all. Try this with the command-line pcre
test client. If it works there and not in PHP, then you can blame PHP.
----
[2005-10-03 08:42:28] php at koterov dot ru
First. Quoting this article:
<<<
There are some size limitations in PCRE but it is hoped that
they will
never in practice be relevant.
The maximum length of a compiled pattern is 65539 (sic) bytes
if PCRE
is compiled with the default internal linkage size of 2. If you
want to
process regular expressions that are truly enormous, you can
compile
PCRE with an internal linkage size of 3 or 4 (see the README
file in
the source distribution and the pcrebuild documentation for
details).
In these cases the limit is substantially larger. However, the
speed
of execution will be slower.
All values in repeating quantifiers must be less than 65536.
The maxi-
mum number of capturing subpatterns is 65535.
There is no limit to the number of non-capturing subpatterns,
but the
maximum depth of nesting of all kinds of parenthesized
subpattern,
including capturing subpatterns, assertions, and other types of
subpat-
tern, is 200.
The maximum length of a subject string is the largest positive
number
that an integer variable can hold. However, when using the
traditional
matching function, PCRE uses recursion to handle subpatterns and
indef-
inite repetition. This means that the available stack space may
limit
the size of a subject string that can be processed by certain
patterns.
>>>
Which limitation did you mean? As you can see, expression
/((?:[^<]|<[^>]*>){1,1000}).*/xs
does not break any limitation bounds quoted above.
Second. The same RE works in Perl 5.6 and 5.8 even with {1,1}
repeating quantifiers. But Perl 5.6 uses wittingly older version of
libpcre than PHP 4.4.0. So, possibly source of bug is not in PCRE, but
in PHP?..
Third. It is NOT a backtracking overflow, because for string with 1001
"a"'s this expression does not work too.
[2005-10-02 13:00:58] [EMAIL PROTECTED]
RTFM: "You should be aware of some limitations of PCRE. Read
http://www.pcre.org/pcre.txt for more info."
--------------------
[2005-10-02 08:46:36] php at koterov dot ru
Snapshot does not work too.
[2005-10-01 10:10:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
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/34695
--
Edit this bug report at http://bugs.php.net/?id=34695&edit=1
#34695 [Bgs->Opn]: preg_replace(): {}-expresion overflow
ID: 34695
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
-Status: Bogus
+Status: Open
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 4.4.0
New Comment:
First. Quoting this article:
<<<
There are some size limitations in PCRE but it is hoped that
they will
never in practice be relevant.
The maximum length of a compiled pattern is 65539 (sic) bytes
if PCRE
is compiled with the default internal linkage size of 2. If you
want to
process regular expressions that are truly enormous, you can
compile
PCRE with an internal linkage size of 3 or 4 (see the README
file in
the source distribution and the pcrebuild documentation for
details).
In these cases the limit is substantially larger. However, the
speed
of execution will be slower.
All values in repeating quantifiers must be less than 65536.
The maxi-
mum number of capturing subpatterns is 65535.
There is no limit to the number of non-capturing subpatterns,
but the
maximum depth of nesting of all kinds of parenthesized
subpattern,
including capturing subpatterns, assertions, and other types of
subpat-
tern, is 200.
The maximum length of a subject string is the largest positive
number
that an integer variable can hold. However, when using the
traditional
matching function, PCRE uses recursion to handle subpatterns and
indef-
inite repetition. This means that the available stack space may
limit
the size of a subject string that can be processed by certain
patterns.
>>>
Which limitation did you mean? As you can see, expression
/((?:[^<]|<[^>]*>){1,1000}).*/xs
does not break any limitation bounds quoted above.
Second. The same RE works in Perl 5.6 and 5.8 even with {1,1}
repeating quantifiers. But Perl 5.6 uses wittingly older version of
libpcre than PHP 4.4.0. So, possibly source of bug is not in PCRE, but
in PHP?..
Third. It is NOT a backtracking overflow, because for string with 1001
"a"'s this expression does not work too.
Previous Comments:
[2005-10-02 13:00:58] [EMAIL PROTECTED]
RTFM: "You should be aware of some limitations of PCRE. Read
http://www.pcre.org/pcre.txt for more info."
--------------------
[2005-10-02 08:46:36] php at koterov dot ru
Snapshot does not work too.
[2005-10-01 10:10:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
--------------------
[2005-09-30 23:47:44] php at koterov dot ru
Description:
PCRE /X{1,Y}/ for large Y (near 1000) does not work for some X on
Windows (apache 1.3+mod_php 4.4.0 or 4.3.10). In Unix (Linux) -
everything is fine. Maybe stack overflow?
Reproduce code:
---
]* >){1,'.MAXLEN.'}) .* /xs',
'$1', $text);
die('ok');
?>
Expected result:
ok
Actual result:
--
nothing (php exits, but no windows GPF)
--
Edit this bug report at http://bugs.php.net/?id=34695&edit=1
#34695 [Fbk->Opn]: preg_replace(): {}-expresion overflow
ID: 34695
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 4.4.0
New Comment:
Snapshot does not work too.
Previous Comments:
[2005-10-01 10:10:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-09-30 23:47:44] php at koterov dot ru
Description:
PCRE /X{1,Y}/ for large Y (near 1000) does not work for some X on
Windows (apache 1.3+mod_php 4.4.0 or 4.3.10). In Unix (Linux) -
everything is fine. Maybe stack overflow?
Reproduce code:
---
]* >){1,'.MAXLEN.'}) .* /xs',
'$1', $text);
die('ok');
?>
Expected result:
ok
Actual result:
--
nothing (php exits, but no windows GPF)
--
Edit this bug report at http://bugs.php.net/?id=34695&edit=1
#34695 [NEW]: preg_replace(): {}-expresion overflow
From: php at koterov dot ru
Operating system: Windows XP
PHP version: 4.4.0
PHP Bug Type: Reproducible crash
Bug description: preg_replace(): {}-expresion overflow
Description:
PCRE /X{1,Y}/ for large Y (near 1000) does not work for some X on Windows
(apache 1.3+mod_php 4.4.0 or 4.3.10). In Unix (Linux) - everything is
fine. Maybe stack overflow?
Reproduce code:
---
]* >){1,'.MAXLEN.'}) .* /xs',
'$1', $text);
die('ok');
?>
Expected result:
ok
Actual result:
--
nothing (php exits, but no windows GPF)
--
Edit bug report at http://bugs.php.net/?id=34695&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34695&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34695&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34695&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34695&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34695&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34695&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34695&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34695&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34695&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34695&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34695&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34695&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34695&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34695&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34695&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34695&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34695&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34695&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34695&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34695&r=mysqlcfg
#33974 [Bgs]: ob_list_handlers(): object-based handlers returned incorrectly.
ID: 33974
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
Status: Bogus
Bug Type: Output Control
Operating System: any
PHP Version: 4.3.11
New Comment:
I'll detalize why do I say all this words. It would be great to
MANUALLY process all output buffers with their callbacks at the end of
script - something like this:
foreach (array_reverse(ob_list_handlers()) as $h) {
$text = ob_get_contents(); ob_end_clean();
echo call_user_func($h, $text);
}
Why? Very simple: if I let the callbacks to be called automatically,
I'll loose ALL errors, warnings and notices in them, because errors are
suppress on standard OB callback execution. But, if I call all the
callbacks manually (see example above), it's OK with errors.
I use OB callbacks very often, an there are a lot of PHP code in them
(e.g. - HTML tag parsing, placeholder substitutions etc.). Callbacks is
a very powerful technique, but - almost undebuggable.
Maybe extend ob_get_status(true) adding valid callback references to
returned array?
Previous Comments:
[2005-08-04 13:49:15] php at koterov dot ru
Very strange, because object-based callbacks works fine with
ob_start(). So I guess that full callback info is stored somewhere.
OK, debug purpose. But - maybe write it explicitly in documentation?
"This function is for debug purposes only. Do not try to use it for
manual callback execution - references will be wrong for object-based
callbacks."
[2005-08-03 15:46:05] [EMAIL PROTECTED]
This is how the engine stores callbacks names.
ob_list_handlers() has nothing to do with it.
This functions is for debugging purposes only and there is nothing said
in the docs that it should return valid callbacks.
----
[2005-08-03 15:35:21] php at koterov dot ru
There is nothing said about this behaviour in the documentation:
http://www.php.net/manual/ru/function.ob-list-handlers.php
And - if I cannot trust the result of ob_list_handlers() (I cannot - it
returns bogus handler names), is this function necessary at all?
[2005-08-03 13:22:51] [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
----
[2005-08-03 12:35:45] php at koterov dot ru
Description:
Seems ob_list_handlers() cannot return handlers represented as object
with method names (see ob_start(array(&$obj, 'F'))). It returns them as
"ClassName::MethodName", not as array(..., ...).
Reproduce code:
---
Expected result:
array(1) { [0]=> array(..., 'F') }
// where "..." is object $obj
Actual result:
--
array(1) { [0]=> string(4) "c::F" }
--
Edit this bug report at http://bugs.php.net/?id=33974&edit=1
#33974 [Bgs]: ob_list_handlers(): object-based handlers returned incorrectly.
ID: 33974
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
Status: Bogus
Bug Type: Output Control
Operating System: any
PHP Version: 4.3.11
New Comment:
Very strange, because object-based callbacks works fine with
ob_start(). So I guess that full callback info is stored somewhere.
OK, debug purpose. But - maybe write it explicitly in documentation?
"This function is for debug purposes only. Do not try to use it for
manual callback execution - references will be wrong for object-based
callbacks."
Previous Comments:
[2005-08-03 15:46:05] [EMAIL PROTECTED]
This is how the engine stores callbacks names.
ob_list_handlers() has nothing to do with it.
This functions is for debugging purposes only and there is nothing said
in the docs that it should return valid callbacks.
[2005-08-03 15:35:21] php at koterov dot ru
There is nothing said about this behaviour in the documentation:
http://www.php.net/manual/ru/function.ob-list-handlers.php
And - if I cannot trust the result of ob_list_handlers() (I cannot - it
returns bogus handler names), is this function necessary at all?
[2005-08-03 13:22:51] [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
[2005-08-03 12:35:45] php at koterov dot ru
Description:
Seems ob_list_handlers() cannot return handlers represented as object
with method names (see ob_start(array(&$obj, 'F'))). It returns them as
"ClassName::MethodName", not as array(..., ...).
Reproduce code:
---
Expected result:
array(1) { [0]=> array(..., 'F') }
// where "..." is object $obj
Actual result:
--
array(1) { [0]=> string(4) "c::F" }
--
Edit this bug report at http://bugs.php.net/?id=33974&edit=1
#33975 [Bgs]: ob_end_clean() does call output handler: unadequately result?
ID: 33975 User updated by: php at koterov dot ru Reported By: php at koterov dot ru Status: Bogus Bug Type: Output Control Operating System: any PHP Version: 4.3.11 New Comment: Nothing about this behaviour in documentation, only user comment. Does user comment have the same status as official documentation? Do you thing this behaviour of ob_end_clean() is logical and appropriate? Previous Comments: [2005-08-03 15:02:47] [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 [2005-08-03 13:16:54] php at koterov dot ru Description: Seems ob_end_clean() does call output handler, but not ignore it. It is not adequately I suppose. The same bug is at http://bugs.php.net/bug.php?id=16673, but it is on "No feedback" status and I cannot change it to "Open". Reproduce code: --- Expected result: false Actual result: -- true -- Edit this bug report at http://bugs.php.net/?id=33975&edit=1
#33974 [Bgs->Opn]: ob_list_handlers(): object-based handlers returned incorrectly.
ID: 33974
User updated by: php at koterov dot ru
Reported By: php at koterov dot ru
-Status: Bogus
+Status: Open
Bug Type: Output Control
Operating System: any
PHP Version: 4.3.11
New Comment:
There is nothing said about this behaviour in the documentation:
http://www.php.net/manual/ru/function.ob-list-handlers.php
And - if I cannot trust the result of ob_list_handlers() (I cannot - it
returns bogus handler names), is this function necessary at all?
Previous Comments:
[2005-08-03 13:22:51] [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
[2005-08-03 12:35:45] php at koterov dot ru
Description:
Seems ob_list_handlers() cannot return handlers represented as object
with method names (see ob_start(array(&$obj, 'F'))). It returns them as
"ClassName::MethodName", not as array(..., ...).
Reproduce code:
---
Expected result:
array(1) { [0]=> array(..., 'F') }
// where "..." is object $obj
Actual result:
--
array(1) { [0]=> string(4) "c::F" }
--
Edit this bug report at http://bugs.php.net/?id=33974&edit=1
#33975 [NEW]: ob_end_clean() does call output handler: unadequately result?
From: php at koterov dot ru Operating system: any PHP version: 4.3.11 PHP Bug Type: Output Control Bug description: ob_end_clean() does call output handler: unadequately result? Description: Seems ob_end_clean() does call output handler, but not ignore it. It is not adequately I suppose. The same bug is at http://bugs.php.net/bug.php?id=16673, but it is on "No feedback" status and I cannot change it to "Open". Reproduce code: --- Expected result: false Actual result: -- true -- Edit bug report at http://bugs.php.net/?id=33975&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33975&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33975&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33975&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33975&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33975&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33975&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33975&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33975&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33975&r=support Expected behavior: http://bugs.php.net/fix.php?id=33975&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33975&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33975&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33975&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33975&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33975&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33975&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33975&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33975&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33975&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33975&r=mysqlcfg
#16673 [Com]: callback registered via ob_start is called when not expected
ID: 16673
Comment by: php at koterov dot ru
Reported By: bob at mroczka dot com
Status: No Feedback
Bug Type: Output Control
Operating System: linux 2.4.18
PHP Version: 4.2.0
New Comment:
Bug still exists!
Reproducible code:
It prints "true", so - func() is called on ob_end_clean(), it is not
adequately I suppose.
PHP 4.3.11.
Previous Comments:
[2002-10-19 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2002-09-30 22:09:09] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-05-06 17:53:01] bob at mroczka dot com
with the ob_end_clean call in my code my intention is to discard the
buffer and disable output buffering. i do not have any ob_flush calls
in my code.
here is some background on what i'm trying to do. in a nutshell i have
a call in my code (dio_fcntl) which attempts to get an exclusive lock on
a file. in theory this call can block forever (or until the script
execution timeout occurs). to alert the user that a timeout occurred
while waiting on the lock i create a buffer with an error message just
before the call to the code that may block. if the script gets the
lock before a timeout occurs i call ob_end_clean() to release the error
message in the buffer which is not needed. if a timeout occurs php
flushes this buffer containing the error message and the user is
notified of the error.
the purpose of registering a callback in my case is not to modify the
output buffer (the error message) but to put a message in the web
server error log that this problem occurred. i was expecting the
callback function to not get called when ob_end_clean() is executed.
in theory the callback should only be called in my case if the script
execution timer expires.
some code which can block
[2002-05-03 23:13:30] [EMAIL PROTECTED]
I guess you have some ob_flush() functions, don't you?
[2002-04-17 18:58:31] bob at mroczka dot com
i have the following code where ... represents some
echo statements but does not include any ob_xxx calls.
ob_start("func");
...
ob_end_clean();
and func is defined as:
function func ($buf) {
error_log("got here",0);
return $buf;
}
when this code runs i get "got here" in my error log.
i am expecting the ob_end_clean call to turn off output
buffering which includes not calling the callback I
registered. i am using 4.2.0rc2 currently.
--
Edit this bug report at http://bugs.php.net/?id=16673&edit=1
#33974 [NEW]: ob_list_handlers(): object-based handlers returned incorrectly.
From: php at koterov dot ru
Operating system: any
PHP version: 4.3.11
PHP Bug Type: Unknown/Other Function
Bug description: ob_list_handlers(): object-based handlers returned
incorrectly.
Description:
Seems ob_list_handlers() cannot return handlers represented as object with
method names (see ob_start(array(&$obj, 'F'))). It returns them as
"ClassName::MethodName", not as array(..., ...).
Reproduce code:
---
Expected result:
array(1) { [0]=> array(..., 'F') }
// where "..." is object $obj
Actual result:
--
array(1) { [0]=> string(4) "c::F" }
--
Edit bug report at http://bugs.php.net/?id=33974&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33974&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33974&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33974&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33974&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33974&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33974&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33974&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33974&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33974&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33974&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33974&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33974&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33974&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33974&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33974&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33974&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33974&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33974&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33974&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33974&r=mysqlcfg
#33973 [NEW]: ob_start(create_function(...)): conflict with ob_list_handlers().
From: php at koterov dot ru
Operating system: any
PHP version: 4.3.11
PHP Bug Type: Unknown/Other Function
Bug description: ob_start(create_function(...)): conflict with
ob_list_handlers().
Description:
Seems ob_list_handlers() cannot work with functions created dynamically
using create_function(). "default output handler" is returned.
Reproduce code:
---
Expected result:
array(1) { [0]=> string(...) "name of dynamically created function" }
Actual result:
--
array(1) { [0]=> string(22) "default output handler" }
--
Edit bug report at http://bugs.php.net/?id=33973&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33973&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33973&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33973&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33973&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33973&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33973&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33973&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33973&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33973&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33973&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33973&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33973&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33973&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33973&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33973&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33973&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33973&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33973&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33973&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33973&r=mysqlcfg
#32734 [NEW]: Support for #line pragma, as in C and Perl
From: php at koterov dot ru Operating system: all PHP version: 5.0.4 PHP Bug Type: Feature/Change Request Bug description: Support for #line pragma, as in C and Perl Description: C, C++ and Perl support the folowing feature: // start of file #line 20 "test.c" something #line 30 "test.c" other // end of file If error is generated into code "something", it is reported as error "in test.c on line 20" - NOT on line 3! For code "other" - "in test.c on line 30". The same Perl code example: ### start of file #line 20 "test.c" warn "something"; #line 30 "test.c" warn "other"; ### end of file Result is: something at test.c line 20. other at test.c line 30. Unfortunately PHP does not support this useful feature, and because of that any template engines with pre-compilation (e.g. Smarty) make the life not so pleasant as it could be. Do you plan to add #line feature in future versions of PHP? Programmers need it very much! -- Edit bug report at http://bugs.php.net/?id=32734&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32734&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32734&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32734&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32734&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32734&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32734&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32734&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32734&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32734&r=support Expected behavior: http://bugs.php.net/fix.php?id=32734&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32734&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32734&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32734&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32734&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32734&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32734&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32734&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32734&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32734&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32734&r=mysqlcfg
#31862 [NEW]: Ability to turn off magic_quotes for parse_str().
From: php at koterov dot ru Operating system: all PHP version: 4.3.10 PHP Bug Type: PHP options/info functions Bug description: Ability to turn off magic_quotes for parse_str(). Description: parse_str() always quotes arguments when magic_quotes_gpc is active on startup (php.ini or .htaccess configured). But seems I cannot SWITCH OFF magic_quotes_gpc on runtime FOR parse_str(). (I understand that it is useless to try to switch off magic_quotes_gpc for purposes other than parse_str!). Seems it's a restriction of ini_set(), not parse_str() itself. Reproduce code: --- ".print_r($p, 1).""; ?> Expected result: Array ( [a] => "b" ) Actual result: -- Array ( [a] => \"b\" ) -- Edit bug report at http://bugs.php.net/?id=31862&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31862&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31862&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31862&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31862&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31862&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31862&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31862&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31862&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31862&r=support Expected behavior: http://bugs.php.net/fix.php?id=31862&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31862&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31862&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31862&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31862&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31862&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31862&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31862&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31862&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31862&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31862&r=mysqlcfg
