[PHP-BUG] Bug #62722 [NEW]: incorrect comparison result
From: bo0rsh201 at gmail dot com Operating system: Win7 PHP version: 5.4.5 Package: Variables related Bug Type: Bug Bug description:incorrect comparison result Description: comparision of integer 0 and any string always returns true the problem is independent from operands order. Test script: --- https://bugs.php.net/bug.php?id=62722&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62722&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62722&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62722&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62722&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62722&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62722&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62722&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62722&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62722&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62722&r=support Expected behavior: https://bugs.php.net/fix.php?id=62722&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62722&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62722&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62722&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62722&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62722&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62722&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62722&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62722&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62722&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62722&r=mysqlcfg
Bug #62685 [Opn->Csd]: Wrong return datatype in PDO::inTransaction()
Edit report at https://bugs.php.net/bug.php?id=62685&edit=1
ID: 62685
Updated by: larue...@php.net
Reported by:bgrauer at a2er dot ch
Summary:Wrong return datatype in PDO::inTransaction()
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Windows 7
PHP Version:5.3.15
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-08-02 04:50:05] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=cd896d69d90c70fd13efec315fd8b1f6647497b9
Log: Fixed bug #62685 (Wrong return datatype in PDO::inTransaction())
[2012-07-28 20:35:04] bgrauer at a2er dot ch
Description:
PDO::inTransaction() returns integer instead of boolean values.
MySQL Version: 5.5.25a
Test script:
---
$pdo = new \PDO('mysql:dbname=testdb;host=127.0.0.1', 'testuser', '...');
var_dump($pdo->inTransaction());
$pdo->beginTransaction();
var_dump($pdo->inTransaction());
$pdo->commit();
var_dump($pdo->inTransaction());
Expected result:
boolean false
boolean true
boolean false
Actual result:
--
int 0
int 1
int 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=62685&edit=1
Bug #62716 [Opn->Csd]: munmap() is called with the incorrect length
Edit report at https://bugs.php.net/bug.php?id=62716&edit=1
ID: 62716
Updated by: larue...@php.net
Reported by:slangley at google dot com
Summary:munmap() is called with the incorrect length
-Status: Open
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: All
PHP Version:5.3.15
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-08-01 11:55:48] slangley at google dot com
Description:
In zend_stream.cc the size passed to mmap is the size of the file +
ZEND_MMAP_AHEAD.
*buf = mmap(0, size + ZEND_MMAP_AHEAD, PROT_READ, MAP_PRIVATE,
fileno(file_handle->handle.fp), 0);
However, when munmap() is called the incorrect size is passed.
static void zend_stream_unmap(zend_stream *stream TSRMLS_DC) { /* {{{ */
#if HAVE_MMAP
if (stream->mmap.map) {
munmap(stream->mmap.map, stream->mmap.len);
} else
#endif
The call to munmap should be
munmap(stream->mmap.map, stream->mmap.len + ZEND_MMAP_AHEAD);
Test script:
---
N/A
Expected result:
N/A
Actual result:
--
N/A
--
Edit this bug report at https://bugs.php.net/bug.php?id=62716&edit=1
Bug #62721 [Opn->Fbk]: False positive "Argument ... must be an array, null given"
Edit report at https://bugs.php.net/bug.php?id=62721&edit=1 ID: 62721 Updated by: ahar...@php.net Reported by:register at bazanov dot net Summary:False positive "Argument ... must be an array, null given" -Status: Open +Status: Feedback Type: Bug -Package:Unknown/Other Function +Package:Scripting Engine problem Operating System: Debian PHP Version:5.3.15 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 , 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-08-01 20:33:48] register at bazanov dot net Description: in php.log I see (2 times for the last month): [20-Jul-2012 12:12:32] PHP Catchable fatal error: Argument 2 passed to PendingOrderService::PreparePendingOrder() must be an array, null given, called in /srv/www/example.org/public_html/OrderHelper.php on line 478 and defined in /srv/www/example.org/public_html/bll/PendingOrderService.php on line 58 ... // OrderHelper.php, Line 478: $order = PendingOrderService::PreparePendingOrder($customer, $orderLines, $isDDP, $CustomerOrderN); PendingOrderService::AddOrder($order, $_SESSION['RestrictWithMinPrices']); CustomerActionsLogAccessor::AddLogEntry( $CustomerID, ADD_PENDING_ORDER_FROM_EXCEL, $CustomerOrderN, count($orderLines) . " positions", ''); ... ... // PendingOrderService.php, Line 58: public static function PreparePendingOrder(Customer $customer, array $orderLines, $isDDP, $orderN = null) ... At the same time in my log I see that the order was added on [20-Jul-2012 12:12:32] (same time when fatal error was logged) and the log contains "419 positions", so count($orderLines) executed successfully and it means $orderLines was array and not null. Also I see the saved order in the database with timestamp [20-Jul-2012 12:12:32]. So, everything went fine, $orderLines was not null, but still I got that log entry. -- Edit this bug report at https://bugs.php.net/bug.php?id=62721&edit=1
[PHP-BUG] Bug #62721 [NEW]: False positive "Argument ... must be an array, null given"
From: register at bazanov dot net Operating system: Debian PHP version: 5.3.15 Package: Unknown/Other Function Bug Type: Bug Bug description:False positive "Argument ... must be an array, null given" Description: in php.log I see (2 times for the last month): [20-Jul-2012 12:12:32] PHP Catchable fatal error: Argument 2 passed to PendingOrderService::PreparePendingOrder() must be an array, null given, called in /srv/www/example.org/public_html/OrderHelper.php on line 478 and defined in /srv/www/example.org/public_html/bll/PendingOrderService.php on line 58 ... // OrderHelper.php, Line 478: $order = PendingOrderService::PreparePendingOrder($customer, $orderLines, $isDDP, $CustomerOrderN); PendingOrderService::AddOrder($order, $_SESSION['RestrictWithMinPrices']); CustomerActionsLogAccessor::AddLogEntry( $CustomerID, ADD_PENDING_ORDER_FROM_EXCEL, $CustomerOrderN, count($orderLines) . " positions", ''); ... ... // PendingOrderService.php, Line 58: public static function PreparePendingOrder(Customer $customer, array $orderLines, $isDDP, $orderN = null) ... At the same time in my log I see that the order was added on [20-Jul-2012 12:12:32] (same time when fatal error was logged) and the log contains "419 positions", so count($orderLines) executed successfully and it means $orderLines was array and not null. Also I see the saved order in the database with timestamp [20-Jul-2012 12:12:32]. So, everything went fine, $orderLines was not null, but still I got that log entry. -- Edit bug report at https://bugs.php.net/bug.php?id=62721&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62721&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62721&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62721&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62721&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62721&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62721&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62721&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62721&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62721&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62721&r=support Expected behavior: https://bugs.php.net/fix.php?id=62721&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62721&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62721&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62721&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62721&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62721&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62721&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62721&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62721&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62721&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62721&r=mysqlcfg
Bug #61613 [Com]: No PDO error if first SQL statement of a group is valid.
Edit report at https://bugs.php.net/bug.php?id=61613&edit=1
ID: 61613
Comment by: jonwage at gmail dot com
Reported by:trebitzki at gmx dot net
Summary:No PDO error if first SQL statement of a group is
valid.
Status: Open
Type: Bug
Package:PDO related
Operating System: Mac OS X
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I am experiencing the same issue. Tested on 5.3.5 and 5.3.10 currently.
Previous Comments:
[2012-04-11 23:27:03] trebitzki at gmx dot net
I'm working on 1and1 server with PDO Driver for MySQL, client library version
5.1.49; locally on Mac with PDO Driver for MySQL Client API version mysqlnd
5.0.7-dev - 091210 - $Revision: 304625 $. Both environments show this issue.
[2012-04-11 15:08:20] johan...@php.net
Which PDO driver are you using?
[2012-04-03 22:57:20] trebitzki at gmx dot net
Description:
I am submitting a group of two SQL statements to PDO. The first is valid, the
second has a syntax error. PDO should throw an exception but doesn't. It only
throws an exception when the first statement is invalid.
Test script:
---
//[symfony 1.4 environment]
$conn = Propel::getConnection();
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo_statement = $conn->prepare('SELECT 1; invalidstatement');
$pdo_statement->execute();
Expected result:
I expect to have an error thrown since the group of statements has a syntax
error.
Actual result:
--
No error is thrown.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61613&edit=1
Bug #52130 [Com]: Apache HTTP Server has encountered a problem and needs to close. We are sorry
Edit report at https://bugs.php.net/bug.php?id=52130&edit=1 ID: 52130 Comment by: admin at online102 dot com Reported by:imtiyazali4all at yahoo dot com Summary:Apache HTTP Server has encountered a problem and needs to close. We are sorry Status: Feedback Type: Bug Package:Apache2 related Operating System: Windows XP (SP3) PHP Version:5.3.2 Block user comment: N Private report: N New Comment: you need to install apache new version or install php old version i hope it will help you :) Previous Comments: [2011-12-16 05:25:19] scimitar_24 at hotmail dot com adding the "libmysql.dll" did not solve the problem..:( [2011-04-20 19:32:34] raja dot b dot manian at gmail dot com Copy "libmysql.dll" from php\ folder to your "\Apache2.2\bin\" folder, will solve this issue, no need to disable any extensions. [2010-06-21 15:32:13] imtiyazali4all at yahoo dot com Hi, Thanks for your response. I had to disable the following extensions for Apache to run sucessfully. Any ideas why these extensions dont work for me and the steps to resolve it? thanks a lot! [PHP_INTL] [PHP_OCI8] [PHP_OCI8_11G] [PHP_PDO_MYSQL] [PHP_PDO_OCI] [PHP_PDO_PGSQL] [PHP_PGSQL] [PHP_SYBASE_CT] [2010-06-21 09:44:40] paj...@php.net Disable all extensions and see if it works. Then enable them again one by one to see which one causes a problem. Restart apache between each step. [2010-06-21 03:17:48] imtiyazali4all at yahoo dot com Description: Hi, I have installed Apache 2.2.15 and it was tested successful and working fine. As a next step I installed php-5.3.2-Win32-VC6-x86 on Windows XP SP3.Now when I restart the Apache server I am getting an error the following message "Apache HTTP Server has encountered a problem and needs to close. We are sorry for the inconvenience." and I had been given two options send error report to microsoft and other option is dont send. when i clicked on the error report technical information I could see the following information: C:\DOCUME~1\IMTIYA~1\LOCALS~1\Temp\WERcee8.dir00\httpd.exe.mdmp C:\DOCUME~1\IMTIYA~1\LOCALS~1\Temp\WERcee8.dir00\appcompat.txt I tried restarting the system and also uninstalling and installing Apache and PHP again but I am having the same issue. The Apache error file under the logs folder had the following information: Starting the Apache2.2 service The Apache2.2 service is running. ] Apache/2.2.15 (Win32) configured -- resuming normal operations [Mon Jun 21 01:47:19 2010] [notice] Server built: Mar 4 2010 11:27:46 [Mon Jun 21 01:47:19 2010] [notice] Parent: Created child process 2320 [Mon Jun 21 01:47:20 2010] [notice] Child 2320: Child process is running [Mon Jun 21 01:47:20 2010] [notice] Child 2320: Acquired the start mutex. [Mon Jun 21 01:47:20 2010] [notice] Child 2320: Starting 64 worker threads. [Mon Jun 21 01:47:20 2010] [notice] Child 2320: Starting thread to listen on port 80. [Mon Jun 21 01:53:49 2010] [notice] Parent: Received shutdown signal -- Shutting down the server. [Mon Jun 21 01:53:49 2010] [notice] Child 2320: Exit event signaled. Child process is ending. [Mon Jun 21 01:53:50 2010] [notice] Child 2320: Released the start mutex [Mon Jun 21 01:53:51 2010] [notice] Child 2320: All worker threads have exited. [Mon Jun 21 01:53:51 2010] [notice] Child 2320: Child process is exiting [Mon Jun 21 01:53:51 2010] [notice] Parent: Child process exited successfully. The Apache2.2 service is restarting. Starting the Apache2.2 service The Apache2.2 service is running. pid file C:/Apache2.2/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Mon Jun 21 01:56:33 2010] [warn] pid file C:/Apache2.2/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Mon Jun 21 02:03:48 2010] [warn] pid file C:/Apache2.2/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? Can you please help me out here? please let me know if you need more information Thanks Imtiyaz -- Edit this bug report at https://bugs.php.net/bug.php?id=52130&edit=1
[PHP-BUG] Bug #62717 [NEW]: BC: in PHP 5.4 empty() reports true for simplexmlelement
From: php at sebastianmendel dot de
Operating system:
PHP version: 5.4.5
Package: SimpleXML related
Bug Type: Bug
Bug description:BC: in PHP 5.4 empty() reports true for simplexmlelement
Description:
When laoding XML into SimpleXMLElement and iterating with ->children()
empty() reports true for SimpleXMLElement objects.
In PHP 5.3.16 empty() returns false.
In PHP 5.4.5 empty() returns true.
Test script:
---
$xml = <<
6098881
EOT;
$sxml = new SimpleXMLElement($xml);
foreach ($sxml->children() as $xmlKey => $xmlNode) {
var_dump(
empty($xmlNode), (string) $xmlNode, $xmlNode->asxml()
);
}
$xmlNode = new SimpleXMLElement('501936634a721');
var_dump(
empty($xmlNode), (string) $xmlNode, $xmlNode->asxml()
);
Expected result:
bool(false)
string(7) "6098881"
string(14) "6098881"
bool(false)
string(13) "501936634a721"
string(43) "
501936634a721
"
Actual result:
--
bool(true)
string(7) "6098881"
string(14) "6098881"
bool(false)
string(13) "501936634a721"
string(43) "\n501936634a721\n"
--
Edit bug report at https://bugs.php.net/bug.php?id=62717&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62717&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62717&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62717&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62717&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62717&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62717&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62717&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62717&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62717&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62717&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62717&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62717&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62717&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62717&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62717&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62717&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62717&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62717&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62717&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62717&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62717&r=mysqlcfg
Bug #48225 [Com]: Microseconds output wrong in DateTime::format()
Edit report at https://bugs.php.net/bug.php?id=48225&edit=1 ID: 48225 Comment by: arnoonline at gmail dot com Reported by:knut dot urdalen at gmail dot com Summary:Microseconds output wrong in DateTime::format() Status: Assigned Type: Bug Package:Date/time related Operating System: * PHP Version:5.*, 6CVS (2009-05-09) Assigned To:derick Block user comment: N Private report: N New Comment: I also have this bug within Linux Mint: $ php -v PHP 5.3.6-13ubuntu3.8 with Suhosin-Patch (cli) (built: Jun 13 2012 18:02:19) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies Previous Comments: [2012-05-14 11:38:43] tdenev at kontrax dot bg OS: Slackware 13.37 $ php -v PHP 5.3.8 (cli) (built: Oct 9 2011 13:58:17) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies with Xdebug v2.1.1, Copyright (c) 2002-2011, by Derick Rethans still has this bug, the "u" part is still at 00. [2012-02-24 17:46:14] kissifrot at gmail dot com PHP 5.3.10 on Win32 still has the bug, the "u" part is still at 00. [2011-11-03 02:19:36] rewilliams at crystaltech dot com Still see it in 5.3.6 on OS X [2011-01-23 16:20:32] jmdoren at ok dot cl I have the same problem my OS : Fedora release 14 (Laughlin) my php Version: PHP 5.3.5 (cli) (built: Jan 22 2011 00:55:37) in my php.ini date.timezone=America/Santiago my script: my results: 23-01-2011 8:34:18,00 23-01-2011 8:34:18,00 23-01-2011 8:34:19,00 23-01-2011 8:34:20,00 [2009-05-10 17:38:56] j...@php.net See also bug #45554 and bug #47312 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=48225 -- Edit this bug report at https://bugs.php.net/bug.php?id=48225&edit=1
Bug #62715 [Opn->Csd]: ReflectionParameter::isDefaultValueAvailable() wrong result
Edit report at https://bugs.php.net/bug.php?id=62715&edit=1
ID: 62715
Updated by: larue...@php.net
Reported by:benjamin dot morel at strictcoding dot co dot uk
Summary:ReflectionParameter::isDefaultValueAvailable() wrong
result
-Status: Open
+Status: Closed
Type: Bug
Package:Reflection related
Operating System: CentOS 6.3, Windows 7
PHP Version:5.4.5
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-08-01 12:23:51] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=10642aa9e4f1eb694a8f7b514cc234cb24545744
Log: Fixed bug #62715 (ReflectionParameter::isDefaultValueAvailable() wrong
result)
[2012-08-01 12:22:46] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=10642aa9e4f1eb694a8f7b514cc234cb24545744
Log: Fixed bug #62715 (ReflectionParameter::isDefaultValueAvailable() wrong
result)
[2012-08-01 12:21:35] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=10642aa9e4f1eb694a8f7b514cc234cb24545744
Log: Fixed bug #62715 (ReflectionParameter::isDefaultValueAvailable() wrong
result)
[2012-08-01 11:24:32] benjamin dot morel at strictcoding dot co dot uk
Description:
When ReflectionParameter::isOptional() returns false, because other parameters
after it are required, isDefaultValueAvailable() always return false, even is
there actually is a default value.
I've read this older bug report: https://bugs.php.net/bug.php?id=41382
It looks like at that time, this behaviour had been considerer consistent.
I do think this should be revisited however, as in the example function below,
there is absolutely no way with Reflection to get the default value for the
given parameter.
Reflection is a powerful tool for autowiring in Dependency Injection
containers,
where it is interesting to check whether default parameters are available,
regardless of their order.
Test script:
---
function test(PDO $a = null, $b = 0, array $c) {}
$r = new ReflectionFunction('test');
foreach ($r->getParameters() as $p) {
echo $p->getName();
echo " isDefaultValueAvailable: " .
var_export($p->isDefaultValueAvailable(), true) . "\n";
echo "isOptional: " . var_export($p->isOptional(), true) . "\n";
echo "allowsNull: " . var_export($p->allowsNull(), true) . "\n";
echo "\n";
}
Expected result:
a isDefaultValueAvailable: true
isOptional: false
allowsNull: true
b isDefaultValueAvailable: true
isOptional: false
allowsNull: true
c isDefaultValueAvailable: false
isOptional: false
allowsNull: false
Actual result:
--
a isDefaultValueAvailable: false
isOptional: false
allowsNull: true
b isDefaultValueAvailable: false
isOptional: false
allowsNull: true
c isDefaultValueAvailable: false
isOptional: false
allowsNull: false
--
Edit this bug report at https://bugs.php.net/bug.php?id=62715&edit=1
[PHP-BUG] Bug #62716 [NEW]: munmap() is called with the incorrect length
From: slangley at google dot com
Operating system: All
PHP version: 5.3.15
Package: Scripting Engine problem
Bug Type: Bug
Bug description:munmap() is called with the incorrect length
Description:
In zend_stream.cc the size passed to mmap is the size of the file +
ZEND_MMAP_AHEAD.
*buf = mmap(0, size + ZEND_MMAP_AHEAD, PROT_READ, MAP_PRIVATE,
fileno(file_handle->handle.fp), 0);
However, when munmap() is called the incorrect size is passed.
static void zend_stream_unmap(zend_stream *stream TSRMLS_DC) { /* {{{ */
#if HAVE_MMAP
if (stream->mmap.map) {
munmap(stream->mmap.map, stream->mmap.len);
} else
#endif
The call to munmap should be
munmap(stream->mmap.map, stream->mmap.len + ZEND_MMAP_AHEAD);
Test script:
---
N/A
Expected result:
N/A
Actual result:
--
N/A
--
Edit bug report at https://bugs.php.net/bug.php?id=62716&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62716&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62716&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62716&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62716&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62716&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62716&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62716&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62716&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62716&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62716&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62716&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62716&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62716&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62716&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62716&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62716&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62716&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62716&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62716&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62716&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62716&r=mysqlcfg
[PHP-BUG] Bug #62715 [NEW]: ReflectionParameter::isDefaultValueAvailable() wrong result
From: benjamin dot morel at strictcoding dot co dot uk
Operating system: CentOS 6.3, Windows 7
PHP version: 5.4.5
Package: Reflection related
Bug Type: Bug
Bug description:ReflectionParameter::isDefaultValueAvailable() wrong result
Description:
When ReflectionParameter::isOptional() returns false, because other
parameters
after it are required, isDefaultValueAvailable() always return false, even
is
there actually is a default value.
I've read this older bug report: https://bugs.php.net/bug.php?id=41382
It looks like at that time, this behaviour had been considerer consistent.
I do think this should be revisited however, as in the example function
below,
there is absolutely no way with Reflection to get the default value for the
given parameter.
Reflection is a powerful tool for autowiring in Dependency Injection
containers,
where it is interesting to check whether default parameters are available,
regardless of their order.
Test script:
---
function test(PDO $a = null, $b = 0, array $c) {}
$r = new ReflectionFunction('test');
foreach ($r->getParameters() as $p) {
echo $p->getName();
echo " isDefaultValueAvailable: " .
var_export($p->isDefaultValueAvailable(), true) . "\n";
echo "isOptional: " . var_export($p->isOptional(), true) . "\n";
echo "allowsNull: " . var_export($p->allowsNull(), true) . "\n";
echo "\n";
}
Expected result:
a isDefaultValueAvailable: true
isOptional: false
allowsNull: true
b isDefaultValueAvailable: true
isOptional: false
allowsNull: true
c isDefaultValueAvailable: false
isOptional: false
allowsNull: false
Actual result:
--
a isDefaultValueAvailable: false
isOptional: false
allowsNull: true
b isDefaultValueAvailable: false
isOptional: false
allowsNull: true
c isDefaultValueAvailable: false
isOptional: false
allowsNull: false
--
Edit bug report at https://bugs.php.net/bug.php?id=62715&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62715&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62715&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62715&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62715&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62715&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62715&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62715&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62715&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62715&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62715&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62715&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62715&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62715&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62715&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62715&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62715&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62715&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62715&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62715&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62715&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62715&r=mysqlcfg
Bug #39579 [Com]: Comparing zero & string values in boolean comparison has unexpected behaviour
Edit report at https://bugs.php.net/bug.php?id=39579&edit=1 ID: 39579 Comment by: v dot picture at free dot fr Reported by:iain at workingsoftware dot com dot au Summary:Comparing zero & string values in boolean comparison has unexpected behaviour Status: Not a bug Type: Bug Package:Variables related Operating System: FreeBSD 6.1 PHP Version:5.2.0 Block user comment: N Private report: N New Comment: Hi, I'm wondering why this comparison should be evaluated in a numeric context and not a string context, after all there is no loss with string casting whereas there is a huge risk of doing mistakes with numeric casting: (string) 0 => "0" (string) 42.5 => "42.5" (int) "test" => 0 But ok, let's say it's a normal behavior. "If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number" Then why would PHP decide to do that in a string context ? I mean, when I compare two strings I don't expect PHP to convert everything to numbers ! "10" == "1e1" => true Sorry folks, this really seems like a string context to me. Previous Comments: [2006-11-22 11:36:19] m...@php.net It's not a problem -- it's a feature, and it's documented at the address I've just quoted, which describes evaluation of a string in any numeric context. [2006-11-22 11:14:47] iain at workingsoftware dot com dot au it's not the behaviour of how a string is cast to an integer that i'm talking about, but if i have a comparison: if($value == Class::CONSTANT) and the class constant is a string, it's not immediately apparent that if $value == 0 then this will evaluate to true. maybe warning is too strong, but a notice might be good in the event that a non-strict == operation returns true because one of the operands is 0 and the other operand is a value that evaluates to 0 when cast as an int. anyway, i guess if php has been around for this long without anyone mentioning it yet ... i mean, this is the first time i've come across the problem. if a notice had been emitted it would have been a time saver. [2006-11-22 11:06:57] m...@php.net And, besides, this behaviour is documented at http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion [2006-11-22 09:39:26] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php That's how PHP works and it won't change. [2006-11-22 08:35:22] iain at workingsoftware dot com dot au well it seems to me that at least a warning should be given when comparing an integer 0 to a non-integer value that evaluates to 0 when cast as an int unless an explicit type cast is used without using strict equals. i can see why this behaviour is not a bug, because (int)'SOME STRING' == 0, but it's also has the potential to cause unexpected results/bugs unless you use strict equals everywhere. in this case, i fixed the problem by using === instead of ==, but it took a bit of time to track down the error because there was no warning or anything. i think that it would be better to require someone to do: if($value == (int)'SOME STRING') OR if($value === 'SOME STRING') in order to avoid a warning being emmited if $value == 0. 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=39579 -- Edit this bug report at https://bugs.php.net/bug.php?id=39579&edit=1
Bug #62704 [Opn->Nab]: 3rd argument of DateTime::createFromFormat doesn't work
Edit report at https://bugs.php.net/bug.php?id=62704&edit=1
ID: 62704
Updated by: sala...@php.net
Reported by:jachym dot tousek at gmail dot com
Summary:3rd argument of DateTime::createFromFormat doesn't
work
-Status: Open
+Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: Windows 7 x64
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
For the first "command" please see the note on the DateTime::createFromFormat()
manual page [1] which states:
The timezone parameter and the current timezone are ignored
when the time parameter either contains a UNIX timestamp
(e.g. 946684800) or specifies a timezone
(e.g. 2010-01-28T15:00:00+02:00).
[1] http://php.net/manual/en/datetime.createfromformat.php
Previous Comments:
[2012-07-31 11:35:59] jachym dot tousek at gmail dot com
Description:
I thought these two commands are equal:
DateTime::createFromFormat('U', 1343730289, new DateTimeZone("Europe/Prague"))
DateTime::createFromFormat('U', 1343730289)->setTimeZone(new
DateTimeZone("Europe/Prague"))
However they aren't. If that behaviour is correct (I'm unsure) can you explain
why are they different?
Test script:
---
var_export(
DateTime::createFromFormat('U', 1343730289)->setTimeZone(new
DateTimeZone("Europe/Prague"))->getTimeZone()->getName() ===
DateTime::createFromFormat('U', 1343730289, new
DateTimeZone("Europe/Prague"))->getTimeZone()->getName()
);
Expected result:
true
Actual result:
--
false
--
Edit this bug report at https://bugs.php.net/bug.php?id=62704&edit=1
Bug #62560 [Com]: \ReflectionProperty on Exception::$trace has incorrect internal name
Edit report at https://bugs.php.net/bug.php?id=62560&edit=1 ID: 62560 Comment by: franssen dot roland at gmail dot com Reported by:franssen dot roland at gmail dot com Summary:\ReflectionProperty on Exception::$trace has incorrect internal name Status: Feedback Type: Bug Package:Reflection related Operating System: Ubuntu PHP Version:5.4.4 Block user comment: N Private report: N New Comment: Seems to be fixed in 5.4.5 Previous Comments: [2012-07-14 20:49:59] franssen dot roland at gmail dot com Is the fix available in 5.4.5? Im just a simple programmer using the dotdeb packages... never compiled PHP myself before ;-) [2012-07-14 14:55:23] ras...@php.net Right, we fixed something related to this recently in APC. Grab the svn version and try again. [2012-07-14 08:24:03] franssen dot roland at gmail dot com Test script works as expected when APC is disabled. [2012-07-14 08:07:02] franssen dot roland at gmail dot com Memcached is also enabled. [2012-07-14 08:06:13] franssen dot roland at gmail dot com APC is enabled, but disabled on CLI. This reminds me of issues with \RuntimeException; https://bugs.php.net/bug.php?id=62419#1341752621 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=62560 -- Edit this bug report at https://bugs.php.net/bug.php?id=62560&edit=1
