Bug #62722 [Opn->Nab]: incorrect comparison result
Edit report at https://bugs.php.net/bug.php?id=62722&edit=1 ID: 62722 Updated by: ras...@php.net Reported by:bo0rsh201 at gmail dot com Summary:incorrect comparison result -Status: Open +Status: Not a bug Type: Bug Package:Variables related Operating System: Win7 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: '1'==1 That is, (int)'1' == 1 So (int)'hello world' == 0 it is consistent Weak typing means there will be type juggling when you compare different types. Use === if you want to prevent type juggling. Previous Comments: [2012-08-02 06:59:20] bo0rsh201 at gmail dot com 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
[PHP-BUG] Bug #62724 [NEW]: isset returns false but array_key_exists returns true (int keys)
From: max at kriegt dot es Operating system: Debian 6 PHP version: 5.4.5 Package: Arrays related Bug Type: Bug Bug description:isset returns false but array_key_exists returns true (int keys) Description: Hi, recently realized that isset not returning the same result as array_key_exists does for int-Keys. Test script: --- https://bugs.php.net/bug.php?id=62724&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62724&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62724&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62724&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62724&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62724&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62724&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62724&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62724&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62724&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62724&r=support Expected behavior: https://bugs.php.net/fix.php?id=62724&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62724&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62724&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62724&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62724&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62724&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62724&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62724&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62724&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62724&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62724&r=mysqlcfg
Bug #62724 [Com]: isset returns false but array_key_exists returns true (int keys)
Edit report at https://bugs.php.net/bug.php?id=62724&edit=1 ID: 62724 Comment by: keithm at aoeex dot com Reported by:max at kriegt dot es Summary:isset returns false but array_key_exists returns true (int keys) Status: Open Type: Bug Package:Arrays related Operating System: Debian 6 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: This is not a bug. From the manual page on isset: "Determine if a variable is set and is not NULL." In your example, $foo[0] is null which is why isset returns false. Previous Comments: [2012-08-02 09:36:54] max at kriegt dot es Description: Hi, recently realized that isset not returning the same result as array_key_exists does for int-Keys. Test script: --- https://bugs.php.net/bug.php?id=62724&edit=1
Bug #62724 [Opn->Nab]: isset returns false but array_key_exists returns true (int keys)
Edit report at https://bugs.php.net/bug.php?id=62724&edit=1 ID: 62724 Updated by: ahar...@php.net Reported by:max at kriegt dot es Summary:isset returns false but array_key_exists returns true (int keys) -Status: Open +Status: Not a bug Type: Bug Package:Arrays related Operating System: Debian 6 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: What Keith said. :) Previous Comments: [2012-08-02 09:43:38] keithm at aoeex dot com This is not a bug. From the manual page on isset: "Determine if a variable is set and is not NULL." In your example, $foo[0] is null which is why isset returns false. [2012-08-02 09:36:54] max at kriegt dot es Description: Hi, recently realized that isset not returning the same result as array_key_exists does for int-Keys. Test script: --- https://bugs.php.net/bug.php?id=62724&edit=1
Bug #62724 [Nab]: isset returns false but array_key_exists returns true (int keys)
Edit report at https://bugs.php.net/bug.php?id=62724&edit=1 ID: 62724 User updated by:max at kriegt dot es Reported by:max at kriegt dot es Summary:isset returns false but array_key_exists returns true (int keys) Status: Not a bug Type: Bug Package:Arrays related Operating System: Debian 6 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: Hm - misinterpreted the function. :/ Previous Comments: [2012-08-02 09:46:01] ahar...@php.net What Keith said. :) [2012-08-02 09:43:38] keithm at aoeex dot com This is not a bug. From the manual page on isset: "Determine if a variable is set and is not NULL." In your example, $foo[0] is null which is why isset returns false. [2012-08-02 09:36:54] max at kriegt dot es Description: Hi, recently realized that isset not returning the same result as array_key_exists does for int-Keys. Test script: --- https://bugs.php.net/bug.php?id=62724&edit=1
Bug #62715 [Com]: ReflectionParameter::isDefaultValueAvailable() wrong result
Edit report at https://bugs.php.net/bug.php?id=62715&edit=1
ID: 62715
Comment by: benjamin dot morel at strictcoding dot co dot uk
Reported by:benjamin dot morel at strictcoding dot co dot uk
Summary:ReflectionParameter::isDefaultValueAvailable() wrong
result
Status: Closed
Type: Bug
Package:Reflection related
Operating System: CentOS 6.3, Windows 7
PHP Version:5.4.5
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Thanks for the quick fix, isDefaultValueAvailable() works indeed, but
getDefaultValue() still throws an exception:
getParameters() as $p) {
if ($p->isDefaultValueAvailable()) {
var_export($p->getDefaultValue());
}
}
Fatal error: Uncaught exception 'ReflectionException' with message 'Parameter
is
not optional'
Previous Comments:
[2012-08-01 12:24:24] larue...@php.net
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.
[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 #62725 [NEW]: Calling exit() in a shutdown function does not return the exit value
From: ospite at studenti dot unina dot it Operating system: Debian GNU/Linux PHP version: 5.4.5 Package: CGI/CLI related Bug Type: Bug Bug description:Calling exit() in a shutdown function does not return the exit value Description: Calling exit() in a shutdown function behaves differently between php 5.3 and php 5.4 (I tested with the latest stable release 5.4.5 too). The behavior I expect is that the value returned to the calling process is the one from the last exit() in a shutdown function, and php 5.3 honors that assumption, while php 5.4 does not. As a side note, the documentation[1] tells only that calling exit() in a shutdown function blocks executing further shutdown functions but it does not make clear what the returned value will be. [1] http://www.php.net/register_shutdown_function Test script: --- https://bugs.php.net/bug.php?id=62725&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62725&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62725&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62725&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62725&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62725&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62725&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62725&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62725&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62725&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62725&r=support Expected behavior: https://bugs.php.net/fix.php?id=62725&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62725&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62725&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62725&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62725&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62725&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62725&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62725&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62725&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62725&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62725&r=mysqlcfg
[PHP-BUG] Bug #62726 [NEW]: FPM fails to spawn when max_children is set to a high number
From: olemarkus Operating system: Gentoo Linux PHP version: 5.4.5 Package: FPM related Bug Type: Bug Bug description:FPM fails to spawn when max_children is set to a high number Description: With the following parameters set in php-fpm.conf, FPM refuse to start properly. The worker threads are spawned, but hangs and only a kill -9 will stop them. Setting pm.max_children to a lower number works. The exact config works with PHP 5.4.4. pm = static pm.max_children = 500 Some additional information can be found in downstream bug https://bugs.gentoo.org/show_bug.cgi?id=428194 -- Edit bug report at https://bugs.php.net/bug.php?id=62726&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62726&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62726&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62726&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62726&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62726&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62726&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62726&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62726&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62726&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62726&r=support Expected behavior: https://bugs.php.net/fix.php?id=62726&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62726&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62726&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62726&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62726&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62726&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62726&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62726&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62726&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62726&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62726&r=mysqlcfg
Bug #55743 [Com]: date u - Microseconds (added in PHP 5.2.2)
Edit report at https://bugs.php.net/bug.php?id=55743&edit=1 ID: 55743 Comment by: jsuprock at gmail dot com Reported by:bugzilla33 at gmail dot com Summary:date u - Microseconds (added in PHP 5.2.2) Status: Not a bug Type: Bug Package:Date/time related Operating System: All PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Hi, I've experienced this as well, but I do follow your explanation. However, what is the reason for the documentation on this page still being incorrect? http://us2.php.net/manual/en/function.date.php It has been almost a year, and the page still suggests that the "u" formatter will work with date(). Thank you, John Previous Comments: [2011-09-23 13:29:55] bj...@php.net "Note: Since this function only accepts integer timestamps the u format character is only useful when using the date_format() function with user based timestamps created with date_create()." See http://php.net/date [2011-09-20 18:42:46] bugzilla33 at gmail dot com Description: http://pl.php.net/manual/en/function.date.php http://pl.php.net/manual/en/function.gmdate.php Specification: u - Microseconds (added in PHP 5.2.2) - Example: 654321 u formater do not works because second parameter (called timestamp) is int type u formater will works if second parameter (called timestamp) is double (compatible with current int) Please remove u formater useless or fix specyfication or a better fix it int -> double (second parameter) Test script: --- Expected result: 13 13 Actual result: -- 00 00 -- Edit this bug report at https://bugs.php.net/bug.php?id=55743&edit=1
Bug #62715 [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: Closed
Type: Bug
Package:Reflection related
Operating System: CentOS 6.3, Windows 7
PHP Version:5.4.5
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Hi, fixed :)
Previous Comments:
[2012-08-02 10:19:20] benjamin dot morel at strictcoding dot co dot uk
Thanks for the quick fix, isDefaultValueAvailable() works indeed, but
getDefaultValue() still throws an exception:
getParameters() as $p) {
if ($p->isDefaultValueAvailable()) {
var_export($p->getDefaultValue());
}
}
Fatal error: Uncaught exception 'ReflectionException' with message 'Parameter
is
not optional'
[2012-08-01 12:24:24] larue...@php.net
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.
[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)
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=62715
--
Edit this bug report at https://bugs.php.net/bug.php?id=62715&edit=1
Bug #55743 [Nab]: date u - Microseconds (added in PHP 5.2.2)
Edit report at https://bugs.php.net/bug.php?id=55743&edit=1 ID: 55743 Updated by: sala...@php.net Reported by:bugzilla33 at gmail dot com Summary:date u - Microseconds (added in PHP 5.2.2) Status: Not a bug Type: Bug Package:Date/time related Operating System: All PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: The "u" format character does work for date(), it always gives the correct answer of "00" for this function. As explained here and on the date() page, date() itself works with whole seconds for the timestamp. If fractions of seconds are needed, use the DateTime class. Again, the document is correct since the "u" format character exists and does output the number of milliseconds for a given timestamp. However, that number will always be none since date() works with integers, i.e. whole seconds, only. Previous Comments: [2012-08-02 14:03:28] jsuprock at gmail dot com Hi, I've experienced this as well, but I do follow your explanation. However, what is the reason for the documentation on this page still being incorrect? http://us2.php.net/manual/en/function.date.php It has been almost a year, and the page still suggests that the "u" formatter will work with date(). Thank you, John [2011-09-23 13:29:55] bj...@php.net "Note: Since this function only accepts integer timestamps the u format character is only useful when using the date_format() function with user based timestamps created with date_create()." See http://php.net/date [2011-09-20 18:42:46] bugzilla33 at gmail dot com Description: http://pl.php.net/manual/en/function.date.php http://pl.php.net/manual/en/function.gmdate.php Specification: u - Microseconds (added in PHP 5.2.2) - Example: 654321 u formater do not works because second parameter (called timestamp) is int type u formater will works if second parameter (called timestamp) is double (compatible with current int) Please remove u formater useless or fix specyfication or a better fix it int -> double (second parameter) Test script: --- Expected result: 13 13 Actual result: -- 00 00 -- Edit this bug report at https://bugs.php.net/bug.php?id=55743&edit=1
Bug #62725 [Opn->Csd]: Calling exit() in a shutdown function does not return the exit value
Edit report at https://bugs.php.net/bug.php?id=62725&edit=1
ID: 62725
Updated by: larue...@php.net
Reported by:ospite at studenti dot unina dot it
Summary:Calling exit() in a shutdown function does not
return the exit value
-Status: Open
+Status: Closed
Type: Bug
Package:CGI/CLI related
Operating System: Debian GNU/Linux
PHP Version:5.4.5
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
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
Actually, in 5.3 it's not guarantee the exit code will equal to the last call
to
exit
like:
function shutdown()
{
echo 'Script executed with failure', PHP_EOL;
exit(0);
}
register_shutdown_function('shutdown');
exit(1);
$? will be 1.
however I fixed this issue, make 5.4 behavior same as 5.3
Previous Comments:
[2012-08-02 15:03:12] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=d1f0662e4d587754742891f0a179551d8f36674f
Log: Fixed bug #62725 (Calling exit() in a shutdown function does not return
the exit value)
[2012-08-02 15:02:09] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=d1f0662e4d587754742891f0a179551d8f36674f
Log: Fixed bug #62725 (Calling exit() in a shutdown function does not return
the exit value)
[2012-08-02 10:38:56] ospite at studenti dot unina dot it
Description:
Calling exit() in a shutdown function behaves differently between php 5.3 and
php 5.4 (I tested with the latest stable release 5.4.5 too).
The behavior I expect is that the value returned to the calling process is the
one from the last exit() in a shutdown function, and php 5.3 honors that
assumption, while php 5.4 does not.
As a side note, the documentation[1] tells only that calling exit() in a
shutdown function blocks executing further shutdown functions but it does not
make clear what the returned value will be.
[1] http://www.php.net/register_shutdown_function
Test script:
---
https://bugs.php.net/bug.php?id=62725&edit=1
Bug #55743 [Com]: date u - Microseconds (added in PHP 5.2.2)
Edit report at https://bugs.php.net/bug.php?id=55743&edit=1 ID: 55743 Comment by: jsuprock at gmail dot com Reported by:bugzilla33 at gmail dot com Summary:date u - Microseconds (added in PHP 5.2.2) Status: Not a bug Type: Bug Package:Date/time related Operating System: All PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Hi Salathe, I suspected that this was the case based on the API for date() at php.net and the NOTE section. I'm not disagreeing, but my issue is mainly with the documentation... So here's the part where I feel like I need to put in my 2 cents, and I do appreciate your ears regardless of the outcome. (You have been great so far.) With respect to what the NOTE section states, it would probably make more sense to do the following: (1) Disable this formatting character for date() and gmdate(), and specifically remove the formatting character from the documentation on the date() page. (2) Update the DateTime::format() page with an explicit list of formatting characters including the "u". After all, the "u" format character is completely useless in the context of date(), and it really should not be allowed at all. I just think it causes more confusion is all...unless perhaps in the future all PHP date functions will accept microtime(true) (with a precision of 6) instead of time(). Sincerely, John Previous Comments: [2012-08-02 14:21:49] sala...@php.net The "u" format character does work for date(), it always gives the correct answer of "00" for this function. As explained here and on the date() page, date() itself works with whole seconds for the timestamp. If fractions of seconds are needed, use the DateTime class. Again, the document is correct since the "u" format character exists and does output the number of milliseconds for a given timestamp. However, that number will always be none since date() works with integers, i.e. whole seconds, only. [2012-08-02 14:03:28] jsuprock at gmail dot com Hi, I've experienced this as well, but I do follow your explanation. However, what is the reason for the documentation on this page still being incorrect? http://us2.php.net/manual/en/function.date.php It has been almost a year, and the page still suggests that the "u" formatter will work with date(). Thank you, John [2011-09-23 13:29:55] bj...@php.net "Note: Since this function only accepts integer timestamps the u format character is only useful when using the date_format() function with user based timestamps created with date_create()." See http://php.net/date [2011-09-20 18:42:46] bugzilla33 at gmail dot com Description: http://pl.php.net/manual/en/function.date.php http://pl.php.net/manual/en/function.gmdate.php Specification: u - Microseconds (added in PHP 5.2.2) - Example: 654321 u formater do not works because second parameter (called timestamp) is int type u formater will works if second parameter (called timestamp) is double (compatible with current int) Please remove u formater useless or fix specyfication or a better fix it int -> double (second parameter) Test script: --- Expected result: 13 13 Actual result: -- 00 00 -- Edit this bug report at https://bugs.php.net/bug.php?id=55743&edit=1
Bug #48771 [Com]: rename() between drives error: No error
Edit report at https://bugs.php.net/bug.php?id=48771&edit=1
ID: 48771
Comment by: luizael dot batista at gmail dot com
Reported by:bugs at thundercall dot dk
Summary:rename() between drives error: No error
Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: win32 only - Windows XP
PHP Version:5.3CVS-2009-07-02 (snap)
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
hello, when using the rename so
-->rename(dirname(__FILE__)."/modulos/oldfolder",dirname(__FILE__)."/modulos/newfolder");
works correctly ,
when I add a variable triggers an alert stating that the volume syntax is
incorrect :
rename(dirname(__FILE__)."/modulos/oldfolder",dirname(__FILE__)."/modulos/".$name);
how do I fix this?
Previous Comments:
[2011-06-12 15:32:17] paj...@php.net
@tijs_maas at hotmail dot com
Please use a simple:
rename($path1, $path2); as reproduce script, nothing else. That's all this bug
is
about :)
[2011-06-12 15:27:05] tijs_maas at hotmail dot com
I don't know if i am right but i think i also notice this bug. I do not even
use
absolute paths.
I could use this function wrong or it is the bug, it sais: No error on line 19
$pathtothisfolder = explode("/", str_replace(array('//',
'\\'),'/',dirname(__FILE__)));
$pathtoUpperParent = "";
for( $i = 0; $i < count($pathtothisfolder) - 2; $i++ ) {
$pathtoUpperParent .= $pathtothisfolder[$i]."/";
}
$rootname = trim($pathtoUpperParent, versieDirPath());
$parents = count(explode("/", $rootname)) + 2;
$parentpath = "";
while ($parents > 0 ) {
$parentpath .= "../";
$parents --;
}
// voer de rename operatie uit
rename($parentpath.$_GET['versie']."/", $parentpath."sdfsdf/" );
The paths i use are without drives, am I also affected by this bug?
[2010-09-06 13:00:51] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=303070
Log: Per Pierre's e-mail, add a note that the fix for bug #48771 made
cross-drive
renames work in Windows.
[2009-07-06 09:09:33] paj...@php.net
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
[2009-07-02 09:14:32] paj...@php.net
Verified, missing a flag to allow that.
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=48771
--
Edit this bug report at https://bugs.php.net/bug.php?id=48771&edit=1
Bug #61755 [Com]: A parsing bug in the prepared statements can lead to access violations
Edit report at https://bugs.php.net/bug.php?id=61755&edit=1
ID: 61755
Comment by: henri at nerv dot fi
Reported by:noamr at beyondsecurity dot com
Summary:A parsing bug in the prepared statements can lead to
access violations
Status: Closed
Type: Bug
Package:PDO related
Operating System: Windows and Linux
PHP Version:5.4.0
Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
Please use CVE-2012-3450 for this issue.
CVE request: http://www.openwall.com/lists/oss-security/2012/08/02/3
CVE assigned: http://www.openwall.com/lists/oss-security/2012/08/02/7
Previous Comments:
[2012-06-17 07:18:58] henri at nerv dot fi
Does this issue have CVE-identifier? I can request one if you haven't already
done so and someone verifies this is security issue.
[2012-04-19 10:50:46] johan...@php.net
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.
[2012-04-19 09:22:29] johan...@php.net
The following patch has been added/updated:
Patch Name: bug61755.diff
Revision: 1334827349
URL:
https://bugs.php.net/patch-display.php?bug=61755&patch=bug61755.diff&revision=1334827349
[2012-04-17 13:39:31] noamr at beyondsecurity dot com
Description:
Inconsistent parsing of PHP PDO prepared statements. Erroneous design of
parsers
state machine. Under special circumstances parsing of prepared statements does
not stop leading in cycling the whole stack without terminating on \0. This
leads to access violations, accessing of stack data, DoS.
Bug Description
There are several design errors in the state-machine responsible for parsing
PHP
PDO based statement objects. These errors are based on the state-machines
inability to consistently check the supplied SQL-Query. Under special
circumstances an attacker is able to force the responsible PDO code to iterate
beyond the termination of the supplied query string resulting in a buffer out
of
bounds access. This access may lead to uncontrollable as well as attacker
controllable behavior and Access Violations caused by the code iterating the
whole stack and trying to access addresses beyond the stack end.
Preconditions
* PDO is used to access the DB
* For remote attacks: User must be able to directly control any part of the
query string prior its preparation (stm->prepare()). We are well aware that
this
is a general coding fault which leads to other security relevant implications
but sadly enough itâs also quite common in many frameworks, projects to use
prepared statements with user controlled data instead of binding them after
preparation.
* Mysql_real_escape() is no mitigation for this vulnerability. (As stated
above,
there are indeed many projects using user controlled data encoded by
mysql_real_escape() like this: $argName=mysql_real_escape($_GET[âNameâ]);
$db-
>prepare(âSELECT * from âuserâ where âusernameâ=â$argNameâ;
>â).execute();
Test script:
---
(We have several samples, these are some of them)
This poc directly prepares the statements query passed to the script via GET
Request argument âqueryâ.
Examples: poc_pdo_short_get.php?query=/* poc_pdo_short_get.php?query=--:
prepare("SELECT * from
'user'".mysql_real_escape_string($_GET['query']));
$stmt->execute();
//crash
$stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
$stmt->fetch(PDO::FETCH_BOUND);
print_r( $type);
}
catch (Exception $e)
{
echo "Failed: " . $e->getMessage();
}
?>
prepare($sql);
$stmt->execute(); // crashes php worker in pdo_parse_params()
$stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
$stmt->fetch(PDO::FETCH_BOUND);
print_r( $type);
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
?>
prepare($sql);
echo "prepared :)\n";
print_r($stmt);
$stmt->execute(); // crashes php worker in pdo_parse_params()
print_r($stmt);
echo "executed :(\n";
$stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
$stmt->fetch(PDO::FETCH_BOUND);
echo "--data-\n";
print_r( $type);
echo "--data--\n";
} catch (Exception $e) {
echo "EXCEPTION";
echo "Failed: " . $e->getMessage();
}
echo "hmmm end\n";
?>
Actual result:
--
root@bt:/opt/lampp# gdb ./bin/php
(gdb) run poc_pdo_linux_short_1.php
Starting program: /opt/lampp/bin/php /opt/lampp/poc_pdo_linux_short_1.php
[Thread debugging using libthread_db
Bug #62715 [Com]: ReflectionParameter::isDefaultValueAvailable() wrong result
Edit report at https://bugs.php.net/bug.php?id=62715&edit=1
ID: 62715
Comment by: benjamin dot morel at strictcoding dot co dot uk
Reported by:benjamin dot morel at strictcoding dot co dot uk
Summary:ReflectionParameter::isDefaultValueAvailable() wrong
result
Status: Closed
Type: Bug
Package:Reflection related
Operating System: CentOS 6.3, Windows 7
PHP Version:5.4.5
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
I can now confirm this works as expected. Thanks for your time!
Previous Comments:
[2012-08-02 14:26:09] larue...@php.net
Hi, fixed :)
[2012-08-02 10:19:20] benjamin dot morel at strictcoding dot co dot uk
Thanks for the quick fix, isDefaultValueAvailable() works indeed, but
getDefaultValue() still throws an exception:
getParameters() as $p) {
if ($p->isDefaultValueAvailable()) {
var_export($p->getDefaultValue());
}
}
Fatal error: Uncaught exception 'ReflectionException' with message 'Parameter
is
not optional'
[2012-08-01 12:24:24] larue...@php.net
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.
[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)
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=62715
--
Edit this bug report at https://bugs.php.net/bug.php?id=62715&edit=1
[PHP-BUG] Bug #62729 [NEW]: fmod() and "modulo" operator do not work are not consistent with big int.
From: arnaud at wixiweb dot fr Operating system: Linux / Windows PHP version: 5.4.5 Package: Scripting Engine problem Bug Type: Bug Bug description:fmod() and "modulo" operator do not work are not consistent with big int. Description: fmod() and "modulo" operator do not work are not consistent with big int. Moreover, the results change between windows(PHP5.4) to linux(PHP5.3) See the test script for more informations Test script: --- // On Windows64 with PHP 5.4 // Example 1 var_dump(fmod(12345678901234567, 62)); // float(52) var_dump(12345678901234567 % 62);// int(20) // Example 2 var_dump(fmod(111, 62)); // float(18) var_dump(111 % 62); // int(0) // On Linux64 with PHP 5.3 // Example 3 var_dump(fmod(12345678901234567, 62)); // float(52) var_dump(12345678901234567 % 62);// int(51) // Example 4 var_dump(fmod(111, 62)); // float(18) var_dump(111 % 62); // int(-60) -- Edit bug report at https://bugs.php.net/bug.php?id=62729&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62729&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62729&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62729&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62729&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62729&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62729&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62729&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62729&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62729&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62729&r=support Expected behavior: https://bugs.php.net/fix.php?id=62729&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62729&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62729&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62729&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62729&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62729&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62729&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62729&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62729&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62729&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62729&r=mysqlcfg
[PHP-BUG] Bug #62730 [NEW]: mysqlnd mysqlnd_conn_methods table is mot restored correctly with mutliple init
From: slangley at google dot com
Operating system: N/A
PHP version: 5.3.15
Package: MySQL related
Bug Type: Bug
Bug description:mysqlnd mysqlnd_conn_methods table is mot restored correctly
with mutliple init
Description:
If a plugin alters the connection methods table, then the original
connection
table is not restored if there is a php_module_shutdown()/php_module_init()
cycle
in the same process.
This is because mysqlnd_conn_methods is a pointer to
MYSQLND_CLASS_METHOD_TABLE_NAME(mysqlnd_conn),
sizeof(mysqlnd_conn_methods)) so
changing the values in mysqlnd_conn_methods actually changes the values in
the
master table.
To fix, mysqlnd_conn_methods should take a copy of the table on init.
Test script:
---
Create a plugin that replaces the conenct function with a function that
simply flows the call to the original callback.
static enum_func_status
MYSQLND_METHOD(my_test_plugin, query)(MYSQLND* conn,
const char* query, unsigned int query_len TSRMLS_DC) {
return original_conn_methods.query(conn, query, query_len);
}
Register this plugin during MINIT
struct st_mysqlnd_conn_methods* current_conn_methods =
mysqlnd_conn_get_methods();
memcpy(&original_conn_methods,
current_conn_methods,
sizeof(st_mysqlnd_conn_methods));
current_conn_methods->connect = MYSQLND_METHOD(speckle_mysqlnd_conn,
connect);
Start/Stop/Start the php modules
php_module_startup(...)
php_module_shutdown(...)
php_module_startup(...)
Try and connect to the mysqldb - you'll get a stack overflow.
--
Edit bug report at https://bugs.php.net/bug.php?id=62730&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62730&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62730&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62730&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62730&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62730&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62730&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62730&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62730&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62730&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62730&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62730&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62730&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62730&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62730&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62730&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62730&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62730&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62730&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62730&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62730&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62730&r=mysqlcfg
Bug #62729 [Opn->Ana]: fmod() and "modulo" operator do not work are not consistent with big int.
Edit report at https://bugs.php.net/bug.php?id=62729&edit=1 ID: 62729 Updated by: ras...@php.net Reported by:arnaud at wixiweb dot fr Summary:fmod() and "modulo" operator do not work are not consistent with big int. -Status: Open +Status: Analyzed Type: Bug Package:Scripting Engine problem Operating System: Linux / Windows PHP Version:5.4.5 Block user comment: N Private report: N New Comment: Note that longs on 64-bit Windows are still only 32 bits. A long on 64-bit Linux is 64 bits. So, to work with large values like that you will need to use something like bcmod() fmod(x,y) returns x - n * y where n is the quotient of x / y floor'ed and converted to an integer which isn't always going to give you the same result as x % y. If you are working with integers use %. If you are working with doubles, use fmod(). And keep in mind that these are signed so you don't have the whole 32/64 bit space. The upper bit is the sign. Given this I am not sure I see a bug here. You are mostly comparing 32-bit to 64-bit here. Previous Comments: [2012-08-03 00:15:33] arnaud at wixiweb dot fr Description: fmod() and "modulo" operator do not work are not consistent with big int. Moreover, the results change between windows(PHP5.4) to linux(PHP5.3) See the test script for more informations Test script: --- // On Windows64 with PHP 5.4 // Example 1 var_dump(fmod(12345678901234567, 62)); // float(52) var_dump(12345678901234567 % 62);// int(20) // Example 2 var_dump(fmod(111, 62)); // float(18) var_dump(111 % 62); // int(0) // On Linux64 with PHP 5.3 // Example 3 var_dump(fmod(12345678901234567, 62)); // float(52) var_dump(12345678901234567 % 62);// int(51) // Example 4 var_dump(fmod(111, 62)); // float(18) var_dump(111 % 62); // int(-60) -- Edit this bug report at https://bugs.php.net/bug.php?id=62729&edit=1
[PHP-BUG] Req #62732 [NEW]: [Feature Request]Built-in TCP server
From: k at webnfo dot com Operating system: PHP version: 5.4.5 Package: Built-in web server Bug Type: Feature/Change Request Bug description:[Feature Request]Built-in TCP server Description: TCP server can handle much more protocols not only on http. Like smtp, etc. Just accept the tcp message and invoke php to handle the other parts. -- Edit bug report at https://bugs.php.net/bug.php?id=62732&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62732&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62732&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62732&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62732&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62732&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62732&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62732&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62732&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62732&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62732&r=support Expected behavior: https://bugs.php.net/fix.php?id=62732&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62732&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62732&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62732&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62732&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62732&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62732&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62732&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62732&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62732&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62732&r=mysqlcfg
[PHP-BUG] Req #62733 [NEW]: dl function has been removed
From: chopins dot xiao at gmail dot com Operating system: linux PHP version: 5.3.15 Package: *General Issues Bug Type: Feature/Change Request Bug description:dl function has been removed Description: why the function been removed and use the Extension Loading Directives instead if phper can edit php.ini, he has supper permissions, so use dl or use php.ini is no difference, when dl function is removed i can't dynamically load extension if do't hope the extension load when PHP start up -- Edit bug report at https://bugs.php.net/bug.php?id=62733&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62733&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62733&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62733&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62733&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62733&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62733&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62733&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62733&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62733&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62733&r=support Expected behavior: https://bugs.php.net/fix.php?id=62733&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62733&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62733&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62733&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62733&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62733&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62733&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62733&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62733&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62733&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62733&r=mysqlcfg
Req #62733 [Opn->Wfx]: dl function has been removed
Edit report at https://bugs.php.net/bug.php?id=62733&edit=1 ID: 62733 Updated by: ras...@php.net Reported by:chopins dot xiao at gmail dot com Summary:dl function has been removed -Status: Open +Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: linux PHP Version:5.3.15 Block user comment: N Private report: N New Comment: Because if you don't have permission to edit the php.ini you probably shouldn't be loading extensions. Extensions stay loaded after the request and can break very subsequent request. So dl() hasn't been completely removed, it has only been removed from the persistent and threaded SAPIs because they destabilize the server and cannot be done safely. Previous Comments: [2012-08-03 03:39:05] chopins dot xiao at gmail dot com Description: why the function been removed and use the Extension Loading Directives instead if phper can edit php.ini, he has supper permissions, so use dl or use php.ini is no difference, when dl function is removed i can't dynamically load extension if do't hope the extension load when PHP start up -- Edit this bug report at https://bugs.php.net/bug.php?id=62733&edit=1
[PHP-BUG] Req #62734 [NEW]: [Feature Request]Multiple typehint support
From: k at webnfo dot com
Operating system:
PHP version: 5.4.5
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:[Feature Request]Multiple typehint support
Description:
With Multiple typehint support, function arguments can accept multiple
specific type of data.
The syntax would be like this:
function demo(TypeA|ClassA|Array $var){
}
Which will accept the one of those types: TypeA, ClassA, Array as valid
argument.
--
Edit bug report at https://bugs.php.net/bug.php?id=62734&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62734&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62734&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62734&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62734&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62734&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62734&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62734&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62734&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62734&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62734&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62734&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62734&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62734&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62734&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62734&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62734&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62734&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62734&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62734&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62734&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62734&r=mysqlcfg
Req #62734 [Opn->Dup]: [Feature Request]Multiple typehint support
Edit report at https://bugs.php.net/bug.php?id=62734&edit=1
ID: 62734
Updated by: ahar...@php.net
Reported by:k at webnfo dot com
Summary:[Feature Request]Multiple typehint support
-Status: Open
+Status: Duplicate
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
Previously requested as request #31785. I don't think anything's changed,
really: the stock advice of using an interface that defines the API you expect
to be implemented stands, and I don't think the object-or-array case is
important enough to merit this sort of change.
Previous Comments:
[2012-08-03 04:04:44] k at webnfo dot com
Description:
With Multiple typehint support, function arguments can accept multiple specific
type of data.
The syntax would be like this:
function demo(TypeA|ClassA|Array $var){
}
Which will accept the one of those types: TypeA, ClassA, Array as valid
argument.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62734&edit=1
Req #32100 [ReO]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1 ID: 32100 User updated by:ceefour at gauldong dot net Reported by:ceefour at gauldong dot net Summary:Request 'finally' support for exceptions Status: Re-Opened Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:5.* Assigned To:laruence Block user comment: N Private report: N New Comment: Finally! :-) Thanks a lot Previous Comments: [2012-07-26 02:10:42] larue...@php.net RFC complete, https://wiki.php.net/rfc/finally [2012-07-25 23:44:07] pravdin at vl dot ru We are writing large web application on PHP using the OOP and programming patterns. Exceptions are not only error reporting mechanism but also very important program flow mechanism. So, try...finally is commonly needed. Please add this feature. I know, PHP is not OOP, but I think there is no reason to limit developers needs, especially when this needs are not for just a few single developers. [2012-07-24 10:59:57] larue...@php.net I will try to make a implemention. [2012-07-18 23:13:07] pieceofchum at yahoo dot com Hello I am a Java developer and would like to move over to PHP for my current personal projects. The use of finally in Java is extremely powerful as it ensures that a unit of work that uses any resources that need to be managed are guaranteed to be handled before leaving the method even whent here is a catch clause. This has nothing to do with control flow and exception handling it has everything to do with contract based blocks of code in fact finally is a totally unique construct which greatly simplifies algorithms where one needs a guarantee of certain code running (usually to handle external resources) no matter what happens outside of course of an error (error defined as something that breaks the interpreter/compiler/environmen). It is not a mistake of design but a vast improvement in code clarity and application of the DRY principle which is correct programming and has nothing at all to do with improper control flow. It is not a mistake that it is in some form in Python, Ruby, Java etc... Please please recondsider adding this extremely important construct to PHP. Thanks for your consideration in this matter [2012-07-05 20:17:57] angelo at camargo dot ws ++ for finally in PHP 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=32100 -- Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: ceefour at gauldong dot net
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Re-Opened
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:5.*
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
This is awesome !
My next suggestion would be automatic resource management.
e.g. in Scala :
import resource._
val first_ten_bytes = managed(new FileInputStream("test.txt")) map {
input =>
val buffer = new Array[Byte](10)
input.read(buffer)
buffer
}
or in Java 7 :
static String readFirstLineFromFile(String path) throws IOException {
try (BufferedReader br =
new BufferedReader(new FileReader(path))) {
return br.readLine();
}
}
But "finally" as it stands already rocks!!! Hopefully we can see it in PHP
sooner than later. We've been waiting for a little bit too long (7 years)
;-)
Previous Comments:
[2012-08-03 04:38:39] ceefour at gauldong dot net
Finally! :-)
Thanks a lot
[2012-07-26 02:10:42] larue...@php.net
RFC complete, https://wiki.php.net/rfc/finally
[2012-07-25 23:44:07] pravdin at vl dot ru
We are writing large web application on PHP using the OOP and programming
patterns. Exceptions are not only error reporting mechanism but also very
important program flow mechanism. So, try...finally is commonly needed. Please
add
this feature. I know, PHP is not OOP, but I think there is no reason to limit
developers needs, especially when this needs are not for just a few single
developers.
[2012-07-24 10:59:57] larue...@php.net
I will try to make a implemention.
[2012-07-18 23:13:07] pieceofchum at yahoo dot com
Hello I am a Java developer and would like to move over to PHP for my current
personal projects. The use of finally in Java is extremely powerful as it
ensures that a unit of work that uses any resources that need to be managed are
guaranteed to be handled before leaving the method even whent here is a catch
clause. This has nothing to do with control flow and exception handling it has
everything to do with contract based blocks of code in fact finally is a
totally unique construct which greatly simplifies algorithms where one needs a
guarantee of certain code running (usually to handle external resources) no
matter what happens outside of course of an error (error defined as something
that breaks the interpreter/compiler/environmen). It is not a mistake of design
but a vast improvement in code clarity and application of the DRY principle
which is correct programming and has nothing at all to do with improper control
flow. It is not a mistake that it is in some form in Python, Ruby, Java etc...
Please please recondsider adding this extremely important construct to PHP.
Thanks for your consideration in this matter
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=32100
--
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
Req #62733 [Com]: dl function has been removed
Edit report at https://bugs.php.net/bug.php?id=62733&edit=1 ID: 62733 Comment by: chopins dot xiao at gmail dot com Reported by:chopins dot xiao at gmail dot com Summary:dl function has been removed Status: Wont fix Type: Feature/Change Request Package:*General Issues Operating System: linux PHP Version:5.3.15 Block user comment: N Private report: N New Comment: I don't think dl() has safely problem, because the function can disable via set enable_dl to off or ban it. so server's administrator should know aftermath when the dl() is available, I think should disable dl() in default instead of SAPIs removed except CLI and Embed Previous Comments: [2012-08-03 03:42:31] ras...@php.net Because if you don't have permission to edit the php.ini you probably shouldn't be loading extensions. Extensions stay loaded after the request and can break very subsequent request. So dl() hasn't been completely removed, it has only been removed from the persistent and threaded SAPIs because they destabilize the server and cannot be done safely. [2012-08-03 03:39:05] chopins dot xiao at gmail dot com Description: why the function been removed and use the Extension Loading Directives instead if phper can edit php.ini, he has supper permissions, so use dl or use php.ini is no difference, when dl function is removed i can't dynamically load extension if do't hope the extension load when PHP start up -- Edit this bug report at https://bugs.php.net/bug.php?id=62733&edit=1
