#48973 [Opn->Bgs]: gmdate("Y") returns "0000"
ID: 48973
Updated by: scott...@php.net
Reported By: Michael dot Forman at Colorado dot EDU
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Mac OS 10.5.7
PHP Version: 5.2.10
New Comment:
Duplicate of bug #48276
Previous Comments:
[2009-07-18 23:21:31] Michael dot Forman at Colorado dot EDU
Description:
Within Joomla, called from the "libraries/joomla/utilities/data.php"
library, the function gmdate("Y") returns "", whereas gmdate("y")
correctly returns "09". If functions correctly on the command line.
Reproduce code:
---
$date = strtotime(gmdate("M d Y H:i:s", time()));
echo $date;
// This returns "Jul 18 23:05:58".
Expected result:
It should return "Jul 18 2009 23:05:58".
--
Edit this bug report at http://bugs.php.net/?id=48973&edit=1
#48973 [NEW]: gmdate("Y") returns "0000"
From: Michael dot Forman at Colorado dot EDU
Operating system: Mac OS 10.5.7
PHP version: 5.2.10
PHP Bug Type: Date/time related
Bug description: gmdate("Y") returns ""
Description:
Within Joomla, called from the "libraries/joomla/utilities/data.php"
library, the function gmdate("Y") returns "", whereas gmdate("y")
correctly returns "09". If functions correctly on the command line.
Reproduce code:
---
$date = strtotime(gmdate("M d Y H:i:s", time()));
echo $date;
// This returns "Jul 18 23:05:58".
Expected result:
It should return "Jul 18 2009 23:05:58".
--
Edit bug report at http://bugs.php.net/?id=48973&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48973&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48973&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48973&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=48973&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=48973&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48973&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48973&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48973&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48973&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48973&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48973&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48973&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48973&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48973&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48973&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48973&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48973&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48973&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48973&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48973&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48973&r=mysqlcfg
#44294 [Com]: Undefined symbols with libxml2
ID: 44294 Comment by: rdohms at gmail dot com Reported By: danval at gmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Mac 10.5 Leopard Client PHP Version: 5.*, 6CVS (2009-07-09) Assigned To: fb-req-jani New Comment: Jani. Adding /lib was the only way i got it working.. otherwise it skipped those dirs and kep hamerring /usr/lib which is the next in line, like here: cc -bundle -bundle_loader /Applications/Server/Apache2/bin/httpd -L/usr/lib -L/usr/lib -laprutil-1... What i have been doing to compile succesfully is altering to this cc -bundle -bundle_loader /Applications/Server/Apache2/bin/httpd -L/opt/xml/lib -L/opt/local/lib -L/usr/lib -L/usr/lib -laprutil-1... This was gwyne's suggestion and it works great. After I enabled OpenSSL i got evem more of these, hence the /opt/local/lib i also placed there. As for versions, i have reproduced these today on: PHP_5_3, PHP_5_2 and trunk, straight from SVN I'm rdohms on php.pecl if you want to chat about this Previous Comments: [2009-07-17 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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". [2009-07-09 20:43:44] j...@php.net And if you change the version, add a note about it. Now there's no way to know what version you reported this with, what version it works with..etc. [2009-07-09 20:41:49] j...@php.net Remove the /lib from those paths. "rdohms at gmail dot com": Where did you get the idea it's okay to pass that anywhere?! [2009-06-22 13:49:51] rdohms at gmail dot com actualy sorry. I had --with-libxml-dir declared. Tried running it with --enable-xmlreader-/opt/xml/lib, just like the above setting and it broke on the same place as before. [2009-06-22 13:31:48] rdohms at gmail dot com @chregu My ./configure had that and it pointed to /opt/xml/lib .. this only stopped the error for the CLI compile.. not the libphp5.so command. On that one i still had to add the -L directive stated above 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/44294 -- Edit this bug report at http://bugs.php.net/?id=44294&edit=1
#48922 [Fbk]: session_set_save_handler() appears to cause all processing to stop
ID: 48922
Updated by: t...@php.net
Reported By: bobby at indesignfirm dot com
Status: Feedback
Bug Type: Session related
Operating System: RedHat 2.6.9-42.0.8.EL #1
PHP Version: 5.2.10
New Comment:
I *think* I have the same problem. Segfaults on various pages that
don't occur on 5.2.9. I have a session handler using PEAR HTTP_Session,
that saves via MDB2/mysqli to a MySQL database. The common factor seems
to be that they happen during session_save_state.
Here's 5.2.10: (crash in version_compare):
Program received signal SIGSEGV, Segmentation fault.
0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
1978if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
#1 0x71ea5af4 in _efree (ptr=0x78bb7010) at
/usr/src/debug/php-5.2.10/Zend/zend_alloc.c:2311
#2 0x71e3f4ff in php_version_compare (orig_ver1=0x787b7538
"5.2.10", orig_ver2=0x78e41ac0 "5.0") at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:202
#3 0x71e3f58b in zif_version_compare (ht=3,
return_value=0x787bc458, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:222
#4 0x71ef028d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:200
#5 0x71ef4235 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:1739
#6 0x71eefd6f in execute (op_array=0x78a028c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#7 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#8 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#9 0x71eefd6f in execute (op_array=0x78b696e8) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#10 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#11 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#12 0x71eefd6f in execute (op_array=0x78b69588) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#13 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#14 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#15 0x71eefd6f in execute (op_array=0x78b6a728) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#16 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#17 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#18 0x71eefd6f in execute (op_array=0x78e29300) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#19 0x71eb816b in zend_call_function (fci=0x7fffd440,
fci_cache=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:1032
#20 0x71eb66d4 in call_user_function_ex
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr_ptr=0x7fffd4e8,
param_count=2, params=0x787b7670, no_separation=1,
symbol_table=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:640
#21 0x71eb65af in call_user_function
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr=0x787b7c18, param_count=2,
params=0x7fffd590)
at /usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:613
#22 0x71da4785 in ps_call_handler (func=0x78e3eea0, argc=2,
argv=0x7fffd590) at
/usr/src/debug/php-5.2.10/ext/session/mod_user.c:53
#23 0x71da4c2d in ps_write_user (mod_data=0x7221db60,
key=0x78e3f7c0 "59ufo7hqslet38p73jp9na8577",
val=0x78fb1e88
"__HTTP_Session2_Info|i:2;__HTTP_Session2_Idle|i:3600;__HTTP_Session2_Idle_TS|i:1247951369;user_id|s:1:\"6\";audit_user|N;",
vallen=119) at /usr/src/debug/php-5.2.10/ext/session/mod_user.c:141
#24 0x71d9d8ba in php_session_save_current_state () at
/usr/src/debug/php-5.2.10/ext/session/session.c:556
#25 0x71da0fbb in php_session_flush () at
/usr/src/debug/php-5.2.10/ext/session/session.c:1408
#26 0x71da31cc in zm_deactivate_session (type=1,
module_number=17) at
/usr/src/debug/php-5.2.10/ext/session/session.c:2010
#27 0x71ecd24b in module_
#34502 [Com]: method chaining on constructor causes parse error
ID: 34502
Comment by: spidgorny at gmail dot com
Reported By: goat at daholygoat dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.0.5
New Comment:
Here's the ugly trick how to do object instantiation and chaining in
one line:
$view->loginForm = end($_ = array(
$l = new Login(),
$l->render()->chain()->everything()->you()->like()
));
$_ and $l are two unnecessary variables. I told you - it's ugly.
Anybody can make it better?
Any ETA for implementing it in PHP directly?
Hello visitor. Please vote.
Previous Comments:
[2005-09-16 10:00:51] goat at daholygoat dot com
@Johannes:
I don't really get your interpretion of the problem. A() is of course
the constructor (A() in A). The constructor returns an object of type A.
returnStr() is a method of A, so when calling returnStr() on a new A(),
it should invoke returnStr() on a new object of A. For example, in Java
it's fine to do this:
System.out.println(new Object().toString());
Which makes sense because when you _can_ do method chaining (which you
can in PHP5), there are many times where you just want to call one chain
on a new object, instead of seperately instantiating the class.
So I have to go with Derick pointing out it's simply not supported
right now.
[2005-09-14 23:25:33] johan...@php.net
By reading the code I'd expect that A is some function
returning an object. returnStr() being a method of that
object returning a class name used for new. (Somehow a
combination of "new $a;" and a simple
"function_call()->methodCallOnReturnedObject()" which is
possible since PHP 5) I would like some syntax like this,
too - but thinking about it I see too much confusion and
didn't find a nice solution which is clear when reading
code.
I set this to bogus since I think it's too much confusion,
but if you have a nice and clear syntax feel free to
re-open it - I'd be happy, but don't see how this is
possible without logic conflicts :-)
[2005-09-14 21:26:50] der...@php.net
I think this is simply not supported right now, so marking as a Feature
Request
[2005-09-14 21:14:57] goat at daholygoat dot com
Description:
When doing method chaining on a constructor (without seperately
instantiating the object first), a parse error occurs.
Reproduce code:
---
class A
{
private $str;
function A($str)
{
$this->str = $str;
}
function returnStr()
{
return $str;
}
}
echo new A("hello")->returnStr();
Expected result:
The reference to an object of A created with A's constructor would
allow me to call returnStr() on it.
Actual result:
--
I'm getting a parse error.
PHP Parse error: parse error, unexpected T_OBJECT_OPERATOR, expecting
',' or ';'
--
Edit this bug report at http://bugs.php.net/?id=34502&edit=1
#48804 [Bgs]: Overriding results in declaration error
ID: 48804
User updated by: christian dot achatz at adventure-php-framework
Reported By: christian dot achatz at adventure-php-framework
Status: Bogus
Bug Type: Class/Object related
Operating System: CentOS 5.3 (final)
PHP Version: 5.3.0
New Comment:
Hello felipe,
I'm not sure, if I have understood your answer. Defining a default
value using
$input = null
should - in my opinion - let the developer skip this argument in
derived classes. This behaviour has always been up to PHP, since
overloading is not supported. Hence, the behaviour is not consistent,
though.
Thanks for a futher answer on this topic.
Christian
Previous Comments:
[2009-07-18 00:21:35] fel...@php.net
This error is due the default value required for the param., not
because the variable name.
[2009-07-05 15:49:34] christian dot achatz at adventure-php-framework
Description:
As of PHP 5.3.0 my custom class (PageControllerInputFilter) is not
compiling any more. Reason for this is:
Declaration of PageControllerInputFilter::filter() should be compatible
with that of AbstractFilter::filter().
Rewriting the filter() function to signature
"filter($filterInstruction,$input = null)" would solve the problem, but
this is no implementation of the filter() method (e.g. interface
behaviour) on PageControllerInputFilter, but overriding. Hence, the name
of the variables must not be spellt equally. Even in JAVA, you can
freely choose your variable names when overriding a method from a
super-class.
Tests were executed using PHP compiled from source on my centos machine
using
[r...@centos53 ~]# md5sum /root/php53-source/php-5.3.0.tar.bz2
846760cd655c98dfd86d6d97c3d964b0 /root/php53-source/php-5.3.0.tar.bz2
[r...@centos53 ~]# ./configure --with-apxs2=$(which apxs)
--prefix=/root/php53/ --with-zlib --without-pear
[r...@centos53 ~]# make
[r...@centos53 ~]# make install
Reproduce code:
---
abstract class AbstractFilter extends coreObject {
function AbstractFilter(){
}
function filter($filterInstruction,$input = null){
return $input;
}
}
class PageControllerInputFilter extends AbstractFilter {
function PageControllerInputFilter(){
}
function filter($instruction,$content){
return $content;
}
}
Definition of the class coreObject can be seen here:
http://adventurephpfra.svn.sourceforge.net/viewvc/adventurephpfra/branches/php5/1.10/core/pagecontroller/pagecontroller.php?revision=573&view=markup
Expected result:
No fatal, no declaration warning.
Actual result:
--
Declaration of PageControllerInputFilter::filter() should be compatible
with that of AbstractFilter::filter().
Fatal error: Class 'PageControllerInputFilter' not found in
/var/www/html/php53/apps/core/filter/PageControllerInputFilter.php on
line 82.
Package to test this behaviour can be found here:
http://media.adventure-php-framework.org/php53/adventure-demopack-1.10-RC1-2009-07-05-1404-php5.tar.gz.
Just extract into document root and call via browser.
--
Edit this bug report at http://bugs.php.net/?id=48804&edit=1
#48972 [Opn->WFx]: Function names are case-insensitive
ID: 48972 Updated by: der...@php.net Reported By: jgrosch at mooseriver dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: FreeBSD 7.1 PHP Version: 5.2.10 Previous Comments: [2009-07-18 19:57:34] jgrosch at mooseriver dot com Description: Function names are case-insensitive. This is really stupid and makes for very bad code. If you want to really do object oriented code you need to support polymorphism and you can't do that with case-insensitive function names. How about joining us here in the 21st century and fix this. -- Edit this bug report at http://bugs.php.net/?id=48972&edit=1
#48972 [NEW]: Function names are case-insensitive
From: jgrosch at mooseriver dot com Operating system: FreeBSD 7.1 PHP version: 5.2.10 PHP Bug Type: Feature/Change Request Bug description: Function names are case-insensitive Description: Function names are case-insensitive. This is really stupid and makes for very bad code. If you want to really do object oriented code you need to support polymorphism and you can't do that with case-insensitive function names. How about joining us here in the 21st century and fix this. -- Edit bug report at http://bugs.php.net/?id=48972&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48972&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48972&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48972&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=48972&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=48972&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48972&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48972&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48972&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48972&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48972&r=support Expected behavior: http://bugs.php.net/fix.php?id=48972&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48972&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48972&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48972&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48972&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48972&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48972&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48972&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48972&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48972&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48972&r=mysqlcfg
#48971 [NEW]: ZEND_NS_* Macros
From: mike at mikegerwitz dot com
Operating system: GNU/Linux
PHP version: 5.3.0
PHP Bug Type: *General Issues
Bug description: ZEND_NS_* Macros
Description:
PHP 5.3 seems to have missed a few things internally (macro-wise) when it
comes to namespaces. When developing an extension for 5.3, I noticed the
following:
Zend/zend_API.h:93
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info)
It's blank! I do not see any options to submit patches, therefore, this
should be the definition:
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info) \
ZEND_NS_FENTRY(ns, zend_name, name, arg_info, 0)
In addition, PHP_NS_* aliases are missing for the ZEND_NS_* macros. For
example, PHP_FE is an alias to ZEND_FE. Therefore, the following macros
should be added:
#define PHP_NS_FE ZEND_NS_FE
#define PHP_NS_NAMED_FE ZEND_NS_NAMED_FE
#define PHP_NS_DEP_FE ZEND_NS_DEP_FE
#define PHP_NS_FALIAS ZEND_NS_FALIAS
#define PHP_NS_DEP_FALIAS ZEND_NS_DEP_FALIAS
If you could provide me with a means to submit a patch, I would be more
than happy to do it myself, as I feel this to be an important (albeit
minor) addition for extension developers in order to keep things
consistent, and less confusing.
Reproduce code:
---
zend_function_entry php_test_functions[] = {
ZEND_NS_NAMED_FE( "Ns", myfunc, test_myfunc, NULL )
{ NULL, NULL, NULL }
};
---
Expected result:
array(1) {
[0]=>
string(16) "Ns\myfunc"
}
Actual result:
--
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=48971&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48971&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48971&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48971&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=48971&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=48971&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48971&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48971&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48971&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48971&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48971&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48971&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48971&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48971&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48971&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48971&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48971&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48971&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48971&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48971&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48971&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48971&r=mysqlcfg
#48970 [NEW]: A new function for displaying array
From: SaharshTibrewal at gmail dot com Operating system: Does it matter? PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: A new function for displaying array Description: This is a short enhancement of print_r Reproduce code: --- --- >From manual page: internals2.ze3 --- "; echo print_r($array); echo ""; } ?> Expected result: This will show the array in a formatted way -- Edit bug report at http://bugs.php.net/?id=48970&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48970&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48970&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48970&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=48970&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=48970&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48970&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48970&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48970&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48970&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48970&r=support Expected behavior: http://bugs.php.net/fix.php?id=48970&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48970&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48970&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48970&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48970&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48970&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48970&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48970&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48970&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48970&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48970&r=mysqlcfg
#48195 [Com]: iconv link failure
ID: 48195 Comment by: raymond dot plante at gmail dot com Reported By: rickdunn at chez dot com Status: Assigned Bug Type: Compile Failure Operating System: MacOSX 10.5.7 PHP Version: 5.3.0RC2 Assigned To: scottmac New Comment: It's obvious the makefile needs to be patched to search configuration specified library paths first. I hope that there isn't anyone here seriously trying to suggest 'you should just have 1 version of a library on your system'. Previous Comments: [2009-06-15 08:53:00] j...@php.net I'll check them once I get back home in couple of days or so. [2009-06-12 11:03:16] rickdunn at chez dot com Sorry about that -- files sent by e-mail. [2009-06-12 07:06:15] j...@php.net Thanks, but I should propably said "send them via email". Both me and Scott. From the generated Makefiles it's easier to diff what the problem is. I deleted those from this report, quite unreadable here. [2009-06-10 20:52:22] rickdunn at chez dot com I tried the makefile modification and the build was not successful. [2009-06-10 16:41:39] phi...@php.net Sorry to dirty up the bugs database as I'm not sure if #43189 differs from this, so I blindly copied the fix from yimingliu to there hoping it would help. My problem exists in 5.2 and 5.3, both of which require manual changes. Old snippet from Makefile: - libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@ libs/libphp$(PHP_MAJOR_VERSION).so New snippet from Makefile (after manual fix): - libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(CC) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) $(MH_BUNDLE_FLAGS) -o $@ && cp $@ libs/libphp$(PHP_MAJOR_VERSION).so Note: - The change is simply moving around $(MH_BUNDLE_FLAGS). The yimingliu link provides a decent explanation for why this problem may exist. The apache2handler.patch.txt patch does not solve this problem. Configure information: - The following build without problem: ./configure --disable-all --with-iconv=/opt/local ./configure --disable-all --with-xmlrpc --enable-libxml=/opt/local -- with-apxs2 While this requires the change to Makefile: ./configure --disable-all --with-iconv=/opt/local --with-apxs2 Jani, Mac is weird and semi-broken in several respects so messing around with and for example removing old versions of libraries it relies upon can mess things up. This includes libxml2 and libiconv. 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/48195 -- Edit this bug report at http://bugs.php.net/?id=48195&edit=1
#48969 [NEW]: register_shutdown_function() buggy in combination with set_error_handler()
From: bschussek at gmail dot com
Operating system: Linux Ubuntu 9.04
PHP version: 5.2.10
PHP Bug Type: Scripting Engine problem
Bug description: register_shutdown_function() buggy in combination with
set_error_handler()
Description:
I registered both a custom error handler and a custom shutdown function.
When calling require with an invalid filename, the following happens:
1. The "warning" error triggers the handler
2. The "fatal" error fires
3. The shutdown function is called
BUT when the error handler throws an exception, no shutdown function is
called. This DOES work when using trigger_error() instead of throwing the
exception.
Reproduce code:
---
function error_handler()
{
var_dump('ERROR');
throw new Exception('my exception');
}
set_error_handler('error_handler');
function shutdown()
{
var_dump('SHUTDOWN');
}
register_shutdown_function('shutdown');
require 'foobar.php';
Expected result:
string(5) "ERROR"
Fatal error: Uncaught exception 'Exception' with message 'my exception'
string(8) "SHUTDOWN"
Actual result:
--
string(5) "ERROR"
Fatal error: main(): Failed opening required 'foobar.php'
--
Edit bug report at http://bugs.php.net/?id=48969&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48969&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48969&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48969&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=48969&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=48969&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48969&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48969&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48969&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48969&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48969&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48969&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48969&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48969&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48969&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48969&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48969&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48969&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48969&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48969&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48969&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48969&r=mysqlcfg
#48964 [Opn->WFx]: GMP not included in VC6 build of PHP 5.3.0
ID: 48964 Updated by: paj...@php.net Reported By: miquelfire at gmail dot com -Status: Open +Status: Wont fix Bug Type: GNU MP related Operating System: Windows PHP Version: 5.3.0 -Assigned To: +Assigned To: pajoye New Comment: We can't fix it as the GMP library is not available for this configuration and the latest GMP version has possible licensing issues. The VC9 binaries use MPIR which is 100% compatible with GMP, maintained and faster. Previous Comments: [2009-07-17 20:31:13] miquelfire at gmail dot com Description: The Windows binary for PHP 5.3.0 VC6 (both ts and nts) do not include the php_gmp.dll file. I have apps that require GMP but the Apache on the machines using them are the Apache.org provided version. I also don't see a VC6 build for 5.3.1 either so I can't check to see if it will show there. (Do have some 2.0 servers) -- Edit this bug report at http://bugs.php.net/?id=48964&edit=1
#48968 [NEW]: (float) "NAN" gives float(0.0) rather than float(NAN)
From: salsi at icosaedro dot it Operating system: PHP version: 5.3.0 PHP Bug Type: *General Issues Bug description: (float) "NAN" gives float(0.0) rather than float(NAN) Description: The (float) typecast operator applied to a string is expected to return the floating point number represented by the string, instead the special values "NAN", "INF" and "-INF" are not handled properly and give 0.0, 0.0 and -0.0 respectively. To make the (float) operator applied to a string symmetrical versus the (string) operator applied to a float, the special strings "NAN", "INF" and "-INF" case sensitive should be translated into NAN, INF and -INF respectively: $f = NAN; $s = (string) $f; # ==> "NAN" $g = (float) $s; # ==> NAN again Apparently the serialize/unserialize process works properly as it was fixed in bug #27646: var_dump( unserialize(serialize(NAN)) ) ==> float(NAN) Reproduce code: --- var_dump( (float) "INF" ); # expected float(INF) var_dump( (float) "-INF" ); # expected float(-INF) var_dump( (float) "NAN" ); # expected float(NAN) Expected result: float(INF) float(-INF) float(NAN) Actual result: -- float(0) float(-0) float(0) -- Edit bug report at http://bugs.php.net/?id=48968&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48968&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48968&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48968&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=48968&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=48968&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48968&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48968&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48968&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48968&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48968&r=support Expected behavior: http://bugs.php.net/fix.php?id=48968&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48968&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48968&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48968&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48968&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48968&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48968&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48968&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48968&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48968&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48968&r=mysqlcfg
#48966 [NEW]: namespace in soap headers not put into nested tags
From: moographics at gmail dot com
Operating system: OSX
PHP version: 5.2.10
PHP Bug Type: Unknown/Other Function
Bug description: namespace in soap headers not put into nested tags
Description:
This has been reported before #40318 and marked as bogus but it is not
bogus - it simply fails to work as expected.
When using soap classes the generated xml header does not have the
namespace prefix for all the tags.
When creating a soap header the soapVar is passed. The xml that is
generated has the correct namespace prefix for the outer tag that is
generated but the inner tags have no prefix. Bug #40318 suggests that
the namespace cannot be guessed for the inner tags. I am suggesting that
the namespace for the inner tags surely can be assumed from the outer
tags namespace. The suggested workaround did not work for me. My
workaround was to roll my own xml.
Reproduce code:
---
class AuthHeader {
private $UsernameToken;
public function __construct($username,$password) {
$this->UsernameToken = new AuthDetails($username,$password);
}
}
class AuthDetails {
private $Username;
private $Password;
public function __construct($username,$password) {
$this->Username = $username;
$this->Password = $password;
}
}
$auth = new AuthHeader('xxx','xxx');
$security_ns = 'http://namespace';
$authvalues = new SoapVar($auth, SOAP_ENC_OBJECT);
$header = new SoapHeader($security_ns, 'Security', $authvalues);
Expected result:
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://namespace1.xsd"; xmlns:ns2="http://namespace2.xsd";>
xxx'
xxx
courseList
review
courseList
2009-07-18T17:28:40
XXX
Actual result:
--
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://namespace1.xsd"; xmlns:ns2="http://namespace2.xsd";>
XXX'
XXX
courseList
review
courseList
2009-07-18T17:28:40
XXX
--
Edit bug report at http://bugs.php.net/?id=48966&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48966&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48966&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48966&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=48966&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=48966&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48966&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48966&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48966&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48966&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48966&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48966&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48966&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48966&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48966&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48966&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48966&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48966&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48966&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48966&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48966&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48966&r=mysqlcfg
#48774 [Opn]: SIGSEGVs when using curl_copy_handle()
ID: 48774
Updated by: srina...@php.net
Reported By: fel...@php.net
Status: Open
Bug Type: cURL related
Operating System: Linux
PHP Version: 5.3CVS-2009-07-02 (CVS)
-Assigned To:
+Assigned To: srinatar
New Comment:
while looking into this bug, i also realized that this below test case
is also broken
less curl_copy_handle_basic_002.phpt
...
curl_setopt($ch, CURLOPT_POSTFIELDS,
"Hello=World&Foo=Bar&Person=John%20Doe");
curl_setopt($ch, CURLOPT_URL, $url); //set the url we want to use
$copy = curl_copy_handle($ch);
curl_close($ch);
...
(currently, marked as expected failure..) so, i have filed a separate
bug : 48965 to track this separately
Previous Comments:
[2009-07-14 09:40:45] sriram dot natarajan at gmail dot com
Hi
though the above patch does fix the crash reported by the developer,
on further investigation this patch is not the right fix.
the issue that is happening is when the form input data is a array, the
constructed form data is not available when executing curl_exec on the
cloned handle.
[2009-07-11 10:54:13] sriram dot natarajan at gmail dot com
here is a better way to read the patches..
http://pastebin.org/1041
[2009-07-11 10:12:27] sriram dot natarajan at gmail dot com
i was able to reproduce this on rhel 5 which ships with curl 7.15.5.
and this below patch seems to fix this problem
--- ext/curl/interface.c.ORIG 2009-07-09 15:24:00.0 -0700
+++ ext/curl/interface.c2009-07-11 03:08:56.0 -0700
@@ -1444,9 +1444,13 @@
zend_llist_copy(&dupch->to_free.str, &ch->to_free.str);
/* Don't try to free copied strings, they're free'd when the
original handle is destroyed */
dupch->to_free.str.dtor = NULL;
-#endif
+
zend_llist_copy(&dupch->to_free.slist, &ch->to_free.slist);
+ dupch->to_free.slist.dtor = NULL;
+
zend_llist_copy(&dupch->to_free.post, &ch->to_free.post);
+ dupch->to_free.post.dtor = NULL;
+#endif
ZEND_REGISTER_RESOURCE(return_value, dupch, le_curl);
dupch->id = Z_LVAL_P(return_value);
need to investigate and possibly add couple of test cases
[2009-07-09 16:31:59] daniel at haxx dot se
I think it would help the devs if you'd also specify what libcurl
version you use (preferably with curl -V or similar to give all the
details).
[2009-07-02 13:20:33] fel...@php.net
Description:
See below.
Reproduce code:
---
1º
http://localhost/";;
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, array("Hello" => "World"));
curl_setopt($ch, CURLOPT_URL, $url);
$copy = curl_copy_handle($ch);
curl_close($ch);
2º
http://localhost/";;
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, array("Hello" => "World"));
curl_setopt($ch, CURLOPT_URL, $url);
$copy = curl_copy_handle($ch);
curl_close($ch);
curl_exec($copy);
curl_close($copy);
Expected result:
No SIGSEGV.
Actual result:
--
1º
*** glibc detected *** sapi/cli/php: double free or corruption
(fasttop): 0x0a663260 ***
=== Backtrace: =
/lib/i686/cmov/libc.so.6[0xb65a81d4]
/lib/i686/cmov/libc.so.6(cfree+0x96)[0xb65aa186]
/usr/local/lib/libcurl.so.4(curl_formfree+0x8a)[0xb74533ca]
sapi/cli/php[0x819c1af]
sapi/cli/php(zend_llist_destroy+0x33)[0x8612f05]
sapi/cli/php(zend_llist_clean+0x11)[0x8612f71]
sapi/cli/php[0x81a0a40]
sapi/cli/php[0x81a0d81]
sapi/cli/php[0x86321e4]
sapi/cli/php(zend_hash_del_key_or_index+0x192)[0x862f5d9]
sapi/cli/php(_zend_list_delete+0xa0)[0x8631df4]
sapi/cli/php(_zval_dtor_func+0x198)[0x861cb28]
sapi/cli/php[0x860cfcc]
sapi/cli/php(_zval_ptr_dtor+0xb8)[0x860d3b1]
sapi/cli/php(_zval_ptr_dtor_wrapper+0x21)[0x861cf08]
sapi/cli/php[0x862fa96]
sapi/cli/php(zend_hash_graceful_reverse_destroy+0x3e)[0x862fc1a]
sapi/cli/php[0x860c5bb]
sapi/cli/php[0x861f79a]
sapi/cli/php(php_request_shutdown+0x682)[0x8590ac0]
sapi/cli/php[0x87035c7]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb654f775]
sapi/cli/php[0x8078a91]
2º
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb631a6f0 (LWP 4050)]
0xb74ef368 in curl_formfree () from /usr/local/lib/libcurl.so.4
Current language: auto; currently asm
(gdb) bt
#0 0xb74ef368 in curl_formfree () from /usr/local/lib/libcurl.so.4
#1 0xb74ef37c in curl_formfree () from /usr/local/lib/libcurl.so.4
#2 0x0819c1af in curl_free_post (post=0xaa1741c) at
/home/felipe/dev/php5/ext/curl/interface.c:1246
#3 0x0
#48965 [NEW]: curl is not able to post a string properly from a cloned handle
From: sriram dot natarajan at gmail dot com
Operating system: linux
PHP version: 5.3.0
PHP Bug Type: cURL related
Bug description: curl is not able to post a string properly from a cloned
handle
Description:
currently, within php tests, the following tests are marked as 'expected
failures'
curl_copy_handle_basic_002.phpt
curl_copy_handle_basic_005.phpt
which both does some thing like
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,
"Hello=World&Foo=Bar&Person=John%20Doe");
$copy = curl_copy_handle($ch);
curl_close($ch);
$curl_content_copy = curl_exec($copy);
curl_close($copy);
var_dump( $curl_content_copy );
Expected result:
these tests should pass fine.
Actual result:
--
string(163) "array(1) {
["test"]=>
string(7) "getpost"
}
--
Edit bug report at http://bugs.php.net/?id=48965&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48965&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48965&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48965&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=48965&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=48965&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48965&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48965&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48965&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48965&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48965&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48965&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48965&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48965&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48965&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48965&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48965&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48965&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48965&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48965&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48965&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48965&r=mysqlcfg
