Bug #54096 [Asn-Csd]: wrong behavior FILTER_VALIDATE_INT -0 +0
Edit report at https://bugs.php.net/bug.php?id=54096edit=1
ID: 54096
Updated by: m...@php.net
Reported by:_coola_ at arcor dot de
Summary:wrong behavior FILTER_VALIDATE_INT -0 +0
-Status: Assigned
+Status: Closed
Type: Bug
Package:Filter related
Operating System: -
PHP Version:Irrelevant
Assigned To:mj
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-12-26 10:59:02] m...@php.net
The PR in https://github.com/php/php-src/pull/248 addresses this issue.
[2011-02-24 19:54:14] _coola_ at arcor dot de
It would also be nice if anybody would care about
http://bugs.php.net/bug.php?id=53775
[2011-02-24 19:51:27] _coola_ at arcor dot de
Description:
Bug report #47752
error_reporting(-1);
var_dump(filter_var('-0',FILTER_VALIDATE_INT)); // bool(false)
var_dump(-0); // int(0)
In my opinion FILTER_VALIDATE_INT must work like var_dump(-0);
Sooner or later we will get problems if everything works different.
PHP defines -0 as an int. So FILTER_VALIDATE_INT must also accept -0 and +0.
Thank you
--
Edit this bug report at https://bugs.php.net/bug.php?id=54096edit=1
Bug #63868 [Opn-Nab]: PDO construct breaks exception chain
Edit report at https://bugs.php.net/bug.php?id=63868edit=1
ID: 63868
Updated by: johan...@php.net
Reported by:mattsch at gmail dot com
Summary:PDO construct breaks exception chain
-Status: Open
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Gentoo
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
This doesn't seem like anything fitting in PDO design (and btw. this affects
any function which might throw an exception...)
Previous Comments:
[2012-12-28 18:14:50] mattsch at gmail dot com
Description:
The pdo construct has no way of continuing the exception chain. It needs
another parameter at the end so you can pass in the previous exception. For
that matter, is there any kind of effort to add exception chaining parameters
for all php classes that throw exceptions?
Test script:
---
?php
class MyCustomException extends Exception {}
function doStuff() {
try {
throw new InvalidArgumentException(You are doing it wrong!, 112);
} catch(Exception $e) {
try {
$pdo = new PDO('foo', 'foo', 'bar', array()); // exception
chain lost
// $pdo = new PDO('foo', 'foo', 'bar', array(), $e); // needs
additional previous exception parameter
} catch (Exception $ex) {
throw new MyCustomException(Something happened, 911, $ex);
}
}
}
try {
doStuff();
} catch(Exception $e) {
do {
printf(%s:%d %s (%d) [%s]\n, $e-getFile(), $e-getLine(),
$e-getMessage(), $e-getCode(), get_class($e));
} while($e = $e-getPrevious());
}
Expected result:
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
foo.php:7 You are doing it wrong! (112) [InvalidArgumentException]
Actual result:
--
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
--
Edit this bug report at https://bugs.php.net/bug.php?id=63868edit=1
Bug #63870 [Opn-Fbk]: apache is generating the more core files and going to maintanance mode
Edit report at https://bugs.php.net/bug.php?id=63870edit=1 ID: 63870 Updated by: johan...@php.net Reported by:skatta at ftc dot gov Summary:apache is generating the more core files and going to maintanance mode -Status: Open +Status: Feedback Type: Bug Package:Apache2 related Operating System: solaris 10 x86 PHP Version:5.3.20 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2012-12-28 20:53:18] skatta at ftc dot gov Description: skatta@hq1-webdmz-s3 $ php -version PHP 5.3.18 (cli) (built: Nov 20 2012 15:33:10) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies skatta@hq1-webdmz-s3 $ skatta@hq1-webdmz-s3 $ /usr/local/apache/bin/httpd -v Server version: Apache/2.2.23 (Unix) Server built: Nov 13 2012 12:53:00 root@hq1-webdmz-s3 # uname -a SunOS hq1-webdmz-s3.ftc.gov 5.10 Generic_147441-24 i86pc i386 i86pc root@hq1-webdmz-s3 # Hi, Seems,httpd was going to maintanace mode after generation of lot of core files to /var/core. Here is the one of the core file info by running the pstack cmd. Please advice us how I can fix this problem. Thanks, Srinivas ska...@ftc.gov -- root@hq1-webdmz-s3 # pstack core_hq1-webdmz-s3.ftc.gov_httpd_800_800_1356721913_15496 core 'core_hq1-webdmz-s3.ftc.gov_httpd_800_800_1356721913_15496' of 15496: /usr/local/apache/bin/httpd -k start ec835356 (86c14b0, 8046cd0, 8046cb0, 8046cb4, 8046cb8, 8666204) fd377559 php_iconv_string (83697d4, 2c, 8046cf0, 8046cf4, 86a39c4) + a1 fd37a4a4 php_if_iconv (3, 8679370, 0, 0, 1, 86463a4) + a0 fd507a26 zend_do_fcall_common_helper_SPEC (8047790, 8368e5c, 8046e28, fd8c03e0, 86c4ecc, 1007790) + 92e fd506b79 execute (86463dc, 0, 2, 83685ac, 8046e5c, 8046e64) + 195 fd4e6781 zend_execute_scripts (8, 0, 3, 0, 8047790, 0) + 129 fd49745f php_execute_script (8047790, 84d2490, 9c, fd56998d, 1, 0) + 1df fd569bec php_handler (84f8ba8, 25, 84f8e88, 84fa320) + 270 080834ce ap_run_handler (84f8ba8, 3b, 8047a78, 8083839, 11e1a300, 0) + 2e 080838a3 ap_invoke_handler (84f8ba8, 0, 8047aa8, 80779b2) + af 080b09fd ap_process_request (84f8ba8, 4, 84f8ba8, 84f8ba8) + 18d 080ae3b5 ap_process_http_connection (84ce758, 8115b58, 8047b08, 80891a9) + f1 08088eca ap_run_process_connection (84ce758, 84ce4c0, 8047b88, 80cc24f, fea63c40, 0) + 2e 080cc29e child_main (10, 80cbe00, 1, 0) + 406 080cc476 make_child (fd8c0e80, fd84224f, 0, 4a, fd84248d, fd85b3fc) + d2 080ccfcf ap_mpm_run (8116fb0, 815b0c0, 811f9a0, 811f9a0) + ac3 0807312f main (3, 8047d9c, 8047dac) + 71f 0807260c _start (3, 8047e48, 8047e64, 8047e67, 0, 8047e6d) + 60 -- -- Edit this bug report at https://bugs.php.net/bug.php?id=63870edit=1
Bug #63228 [Csd-Asn]: -Werror=format-security error in lsapi code
Edit report at https://bugs.php.net/bug.php?id=63228edit=1 ID: 63228 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:-Werror=format-security error in lsapi code -Status: Closed +Status: Assigned Type: Bug Package:Compile Failure PHP Version:5.4.7 Assigned To:gwang Block user comment: N Private report: N New Comment: this is idiotic already. why are you closing this bug with description it is fixed when it is not?! as wrigint of this note (2012-12-29), downloads page says: PHP 5.4.10 (Current stable) Complete Source Code PHP 5.4.10 (tar.bz2) [10,885Kb] - 20 Dec 2012 md5: cb716b657a30570b9b468b9e7bc551a1 and the patch is NOT APPLIED in that release even if you commit is included in php repo, THE COMMIT IS NOT APPEARING in 5.4 series. re-merge the commit or cherry pick it! last commit to the file in 5.4 is 4 months ago, while your commit is 3 months old https://github.com/php/php-src/blob/PHP-5.4.10/sapi/litespeed/lsapi_main.c https://github.com/php/php-src/commits/PHP-5.4.10/sapi/litespeed/lsapi_main.c http://i.imgur.com/uqlx3.png Previous Comments: [2012-12-28 17:04:44] gw...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2012-12-18 07:39:31] glen at delfi dot ee step by step proof that it's not fixed: $ wget http://php.net/get/php-5.4.9.tar.bz2/from/this/mirror -O php- 5.4.9.tar.bz2 $ tar xjf php-5.4.9.tar.bz2 $ grep -n usage php-5.4.9/sapi/litespeed/lsapi_main.c 586:static void cli_usage( TSRMLS_D ) 588:static const char * usage = 606:php_printf( usage ); 744:cli_usage(TSRMLS_C); 788:cli_usage(TSRMLS_C); [2012-12-17 17:57:50] glen at delfi dot ee hey! this is not funny! the commit is not appearing in 5.4.9 release tarball either, please reply where did you commit the fix instead closing it again silently... [2012-11-16 18:01:01] gw...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2012-11-09 09:24:45] glen at delfi dot ee code still not fixed in 5.4.8, what branch did you fix?! :o The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63228 -- Edit this bug report at https://bugs.php.net/bug.php?id=63228edit=1
Bug #63868 [Nab]: PDO construct breaks exception chain
Edit report at https://bugs.php.net/bug.php?id=63868edit=1
ID: 63868
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:PDO construct breaks exception chain
Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Gentoo
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
Since you declared this as not a bug quite quickly, does this mean you have no
intention on allowing an unbroken exception chain within php exceptions? If
that's the case, then why bother implementing exception chaining at all? It's
supposed to help debugging but if the chain gets broken within php core
classes, what's the point?
Previous Comments:
[2012-12-29 12:34:07] johan...@php.net
This doesn't seem like anything fitting in PDO design (and btw. this affects
any function which might throw an exception...)
[2012-12-28 18:14:50] mattsch at gmail dot com
Description:
The pdo construct has no way of continuing the exception chain. It needs
another parameter at the end so you can pass in the previous exception. For
that matter, is there any kind of effort to add exception chaining parameters
for all php classes that throw exceptions?
Test script:
---
?php
class MyCustomException extends Exception {}
function doStuff() {
try {
throw new InvalidArgumentException(You are doing it wrong!, 112);
} catch(Exception $e) {
try {
$pdo = new PDO('foo', 'foo', 'bar', array()); // exception
chain lost
// $pdo = new PDO('foo', 'foo', 'bar', array(), $e); // needs
additional previous exception parameter
} catch (Exception $ex) {
throw new MyCustomException(Something happened, 911, $ex);
}
}
}
try {
doStuff();
} catch(Exception $e) {
do {
printf(%s:%d %s (%d) [%s]\n, $e-getFile(), $e-getLine(),
$e-getMessage(), $e-getCode(), get_class($e));
} while($e = $e-getPrevious());
}
Expected result:
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
foo.php:7 You are doing it wrong! (112) [InvalidArgumentException]
Actual result:
--
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
--
Edit this bug report at https://bugs.php.net/bug.php?id=63868edit=1
[PHP-BUG] Req #63873 [NEW]: Implement exception chaining within core classes
From: mattsch at gmail dot com
Operating system: Gentoo
PHP version: 5.3.20
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:Implement exception chaining within core classes
Description:
php core classes have no way of continuing the exception chain. If we are
to have proper exception chaining as implemented in the exception class in
php 5.3, we should also have the ability to continue the exception chain
within php core classes to make debugging easier.
Test script:
---
?php
class MyCustomException extends Exception {}
function doStuff() {
try {
throw new InvalidArgumentException(You are doing it wrong!,
112);
} catch(Exception $e) {
try {
$pdo = new PDO('foo', 'foo', 'bar', array()); // exception
chain lost
// $pdo = new PDO('foo', 'foo', 'bar', array(), $e); //
needs additional previous exception parameter
} catch (Exception $ex) {
throw new MyCustomException(Something happened, 911,
$ex);
}
}
}
try {
doStuff();
} catch(Exception $e) {
do {
printf(%s:%d %s (%d) [%s]\n, $e-getFile(), $e-getLine(),
$e-getMessage(), $e-getCode(), get_class($e));
} while($e = $e-getPrevious());
}
Expected result:
Expected result:
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
foo.php:7 You are doing it wrong! (112) [InvalidArgumentException]
Actual result:
--
Actual result:
--
foo.php:13 Something happened (911) [MyCustomException]
foo.php:10 invalid data source name (0) [PDOException]
--
Edit bug report at https://bugs.php.net/bug.php?id=63873edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63873r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63873r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63873r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63873r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63873r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63873r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63873r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63873r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63873r=support
Expected behavior: https://bugs.php.net/fix.php?id=63873r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63873r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63873r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63873r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63873r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63873r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63873r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63873r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63873r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63873r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63873r=mysqlcfg
Bug #49382 [Com]: can't access DateTime-date
Edit report at https://bugs.php.net/bug.php?id=49382edit=1
ID: 49382
Comment by: info at metashock dot net
Reported by:klawd at kamundo dot de
Summary:can't access DateTime-date
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Debian GNU/Linux 5.0
PHP Version:5.3.0
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
I think it is interesting that the property can be accessed using reflection.
Using the following example I can access the property:
$dt = new DateTime();
$o = new ReflectionObject($dt);
$p = $o-getProperty('date');
$date = $p-getValue($dt)); // returns the value of DateTime::$date
Previous Comments:
[2010-08-04 22:36:58] weirdan at gmail dot com
if this was not intended to work this way, why won't you just fix it so that no
properties are created as a result of print_r / Reflection::export() /
foreach() /
property_exist / array cast?
[2010-03-07 20:22:06] der...@php.net
-date being available is actually a side-effect of support for var_dump()
here. I'll mark this as a feature request as it was not intended to work.
[2009-08-27 07:52:37] klawd at kamundo dot de
Description:
Can not access property date of DateTime.
Reproduce code:
---
$dt=new DateTime('1742-05-23 00:00:00'); echo $dt-date;
gets me Notice: Undefined property: DateTime::$date
strangely though, this works:
$dt=new DateTime('1742-05-23 00:00:00'); print_r($dt); echo $dt-date;
DateTime Object ( [date] = 1742-05-23 00:00:00 [timezone_type] = 3 [timezone]
= UTC ) 1742-05-23 00:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=49382edit=1
[PHP-BUG] Bug #63874 [NEW]: Buffer overflow if php_strip_whitespace has heredoc
From: igor at wiedler dot ch Operating system: OSX 10.8.2 PHP version: 5.5Git-2012-12-29 (Git) Package: Unknown/Other Function Bug Type: Bug Bug description:Buffer overflow if php_strip_whitespace has heredoc Description: When a filename that contains a heredoc is passed to php_strip_whitespace, it results in a segmentation fault / buffer overflow. Here is the output from --enable-debug: [Sat Dec 29 22:22:09 2012] Script: '/Users/igor/test.php' --- /Users/igor/src/php-src/Zend/zend_highlight.c(189) : Block 0x1036a66d8 status: Beginning: Cached Freed (invalid) Start: OK End: OK --- Test script: --- ?php $contents = php_strip_whitespace(__FILE__); return A a A; -- Edit bug report at https://bugs.php.net/bug.php?id=63874edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63874r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63874r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63874r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63874r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63874r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63874r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63874r=needscript Try newer version: https://bugs.php.net/fix.php?id=63874r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63874r=support Expected behavior: https://bugs.php.net/fix.php?id=63874r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63874r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63874r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63874r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63874r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63874r=dst IIS Stability: https://bugs.php.net/fix.php?id=63874r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63874r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63874r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63874r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63874r=mysqlcfg
Bug #63874 [Opn-Csd]: Segfault if php_strip_whitespace has heredoc
Edit report at https://bugs.php.net/bug.php?id=63874edit=1 ID: 63874 Updated by: pierr...@php.net Reported by:igor at wiedler dot ch Summary:Segfault if php_strip_whitespace has heredoc -Status: Open +Status: Closed Type: Bug Package:Unknown/Other Function Operating System: OSX 10.8.2 PHP Version:5.5Git-2012-12-29 (Git) Block user comment: N Private report: N New Comment: Automatic comment on behalf of pierrick Revision: http://git.php.net/?p=php-src.git;a=commit;h=8228597ecce3ad868d2c6bfca5ff43f29e014296 Log: Fixed bug #63874 (Segfaul if php_strip_whitespace has heredoc) Previous Comments: [2012-12-29 22:32:51] igor at wiedler dot ch Description: When a filename that contains a heredoc is passed to php_strip_whitespace, it results in a segmentation fault / buffer overflow. Here is the output from --enable-debug: [Sat Dec 29 22:22:09 2012] Script: '/Users/igor/test.php' --- /Users/igor/src/php-src/Zend/zend_highlight.c(189) : Block 0x1036a66d8 status: Beginning: Cached Freed (invalid) Start: OK End: OK --- Test script: --- ?php $contents = php_strip_whitespace(__FILE__); return A a A; -- Edit this bug report at https://bugs.php.net/bug.php?id=63874edit=1
[PHP-BUG] Bug #63875 [NEW]: provide a way to handle in Unknown on line 0 errors
From: giorgio dot liscio at email dot it Operating system: any PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:provide a way to handle in Unknown on line 0 errors Description: please read carefully! I really think this is important when an error happens before the actual script execution (main(), unknown on line 0) it is not possible to handle and gracefully display the error in the user space errors may be: post content-length exceeded, file upload size exceeded, max input time... or the equivalent apache errors (LimitRequestBody for instance) note that I'm not sure, or I don't remember, what exactly happens when some of these errors happen, but --some of them don't block the php's execution--, like post_max_size. But when the php's execution isn't blocked I should be able to handle startup errors: nowadays I can't. for example, a big file is uploaded on the server and the post data is limited by some of the above. now, the php page executes anyway because the startup warning doesn't block the execution. But, as I said, in the user space, there is no way what exactly happened and what caused the error, the only way to handle this is (I suppose) parsing error_get_last(). when the big file is sent to the server i may not have the complete form data and in the user space I can't get the proof that is complete. the only thing i can do is if(error_get_last()) throw new Exception(Something went wrong with your request (???)); then something must be done here to fix this problem. I don't have the complete view of the problem but I hope to have been clear so you can fix this. Some functions may be needed: get_startup_errors(); that returns something like this: [0][message] = Post content data limit excedeed ... [0][startupErrType] = STARTUP_ERR_PARTIAL_POST [1][message] = Module 'ssh2' blah blah blah [1][startupErrType] = STARTUP_ERR_SERVER [2]... where startupErrType consists in constants like these: STARTUP_ERR_PARTIAL_POST // partial data sent STARTUP_ERR_EXCEDEED_INPUT_TIME // excedeed input time STARTUP_ERR_EXTENSION // an extension caused the error STARTUP_ERR_SERVER// server caused the startup error I hope to have been clear, my English isn't good. have a happy new year! -- Edit bug report at https://bugs.php.net/bug.php?id=63875edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63875r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63875r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63875r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63875r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63875r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63875r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63875r=needscript Try newer version: https://bugs.php.net/fix.php?id=63875r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63875r=support Expected behavior: https://bugs.php.net/fix.php?id=63875r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63875r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63875r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63875r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63875r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63875r=dst IIS Stability: https://bugs.php.net/fix.php?id=63875r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63875r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63875r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63875r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63875r=mysqlcfg
