[PHP-BUG] Bug #61569 [NEW]: Syntax error for calling a closure using array accesor on function call
From:
Operating system: Windows XP SP3
PHP version: 5.4.0
Package: Compile Failure
Bug Type: Bug
Bug description:Syntax error for calling a closure using array accesor on
function call
Description:
Parse error: syntax error, unexpected '(' in C:\phpinfo.php on line 26
26: giveArray($arrFunctions)[0]("Hello world")
Test script:
---
function($strSomeParam)
{
return $strSomeParam;
},
];
//this works
var_export(
giveArray($arrFunctions)[0]
);
//this works
var_export(
$arrFunctions[0]("Hello world")
);
//this fails compilation with syntax error
var_export(
giveArray($arrFunctions)[0]("Hello world")
);
Expected result:
Closure::__set_state(array(
))'Hello world''Hello world'
Actual result:
--
Parse error: syntax error, unexpected '(' in C:\phpinfo.php on line 26
--
Edit bug report at https://bugs.php.net/bug.php?id=61569&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61569&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61569&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61569&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61569&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61569&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61569&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61569&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61569&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61569&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61569&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61569&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61569&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61569&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61569&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61569&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61569&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61569&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61569&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61569&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61569&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61569&r=mysqlcfg
Bug #41631 [Com]: default_socket_timeout does not work with SSL
Edit report at https://bugs.php.net/bug.php?id=41631&edit=1
ID: 41631
Comment by: oxygenus at gmail dot com
Reported by:david at acz dot org
Summary:default_socket_timeout does not work with SSL
Status: Assigned
Type: Bug
Package:OpenSSL related
Operating System: *
PHP Version:5.2, 5.3
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
This is taking down my servers as well, everytime some other server is down for
maintainance or some network issue occurs.
Previous Comments:
[2011-05-12 17:38:18] mgallelli at gmail dot com
Hi,
i've tested on 5.2.17 and 5.3.2 with the same result.
As described i've used this script:
time php -n -r 'ini_set("default_socket_timeout", 1);
fopen("https://mydomain.it/sleep.php";, "r");'
but it doesn't wait 1 sec but 15 as into sleep.php page.
[2011-03-28 23:51:34] arkadi dot shishlov at gmail dot com
A simple solution is to use HAProxy to proxy SSL partner services. Works for me.
defaults
modetcp
contimeout 5000
clitimeout 3
srvtimeout 3
listen service.gjensidigebaltic.lv 127.0.0.1:10001
dispatch 193.111.247.167:443
listen services.seesam.lv 127.0.0.1:10007
dispatch 217.28.49.7:443
[2011-01-04 00:53:51] guyphp at yahoo dot com
This bug has caused us a lot of headaches due to hung connections from partners
stacking and eventually taking down entire webservers. During high traffic
periods, it doesn't take long for these to reach critical mass. Is there any
ETA
on when this bug will find its way into stable builds? Like many, our managed
hosting provider doesn't support patches - we need a stable build with the fix
integrated.
We are seeing this problem on 5.2.13, RHEL 5.5.
[2010-11-19 15:43:21] chrisw at networkm dot co dot uk
Cannot reproduce this on Windows Server 2003 R2 Enterprise/PHP 5.2.9-2
fopen() returns after $default_socket_timeout seconds if the server does not
respond.
[2010-06-13 15:12:55] fel...@php.net
Pierre, doesn't the attached patch fix this issue?
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=41631
--
Edit this bug report at https://bugs.php.net/bug.php?id=41631&edit=1
Bug #54453 [Com]: LOCK_NB works with LOCK_SH when file locked with LOCK_EX ONLY
Edit report at https://bugs.php.net/bug.php?id=54453&edit=1
ID: 54453
Comment by: oxygenus at gmail dot com
Reported by:teamerx at gmail dot com
Summary:LOCK_NB works with LOCK_SH when file locked with
LOCK_EX ONLY
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Windows XP Centos Ubuntu (latest
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Perhaps the method of running the PHP script should be mentioned. If this is
not
reproducible in CLI mode, then I think something else was at fault, not PHP.
http://stackoverflow.com/a/9827159/584490
Previous Comments:
[2011-04-02 18:42:35] teamerx at gmail dot com
Description:
LOCK_NB works with LOCK_SH when file locked with LOCK_EX ONLY
LOCK_NB doe NOT work with LOCK_SH if file is locked with LOCK_SH
LOCK_NB works with LOCK_EX when file locked with LOCK_SH ONLY
LOCK_NB doe NOT work with LOCK_EX if file is locked with LOCK_EX
preferred output : LOCK_NB should work with LOCK_SH or LOCK_EX no matter what
lock
type the file is locked with
Test script:
---
code 1:
$x = fopen("flocktest.txt", "a");
if (flock($x, LOCK_SH|LOCK_EX|LOCK_NB)) {
print "No problems, I got the lock, now I'm going to sit on it.";
@fwrite($x, 'ddd');
sleep(3);
} else {
print "Didn't quite get the lock. Quitting now. Good night.";
}
fclose($x);
code 2 :
$x = fopen("flocktest.txt", "rb");
if ($x){
if (flock($x, LOCK_SH|LOCK_NB)) {
print "No problems, I got the lock, now I'm going to sit on it.";
@fwrite($fp, 'ddd');
sleep(3);
} else {
print "Didn't quite get the lock. Quitting now. Good night.";
}
fclose($x);
}
if running code 1 then code 1 , lock NB is not working , if running code 1 then
code 2 , lock_nb works
if running code 2 then code 2 , lock_nb does not work , if running code 2 then
code 1 lock nb works .
--
Edit this bug report at https://bugs.php.net/bug.php?id=54453&edit=1
Bug #30471 [Com]: var_export: Nesting level too deep - recursive dependency?
Edit report at https://bugs.php.net/bug.php?id=30471&edit=1
ID: 30471
Comment by: oxygenus at gmail dot com
Reported by:none at example dot com
Summary:var_export: Nesting level too deep - recursive
dependency?
Status: Not a bug
Type: Bug
Package:PHP options/info functions
Operating System: Linux
PHP Version:5.0.2
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
var_export should receive a third param with a flag to detect recursivness and
set
NULL [or some special value such as an instance of an object of class
RecursiveError].
Previous Comments:
[2012-03-28 05:48:38] jodybrabec at gmail dot com
WORKAROUND:
ob_start();
var_dump($GLOBALS);
$dataDump = ob_get_clean();
[2011-03-26 15:21:12] ricki at rocker dot com
I don't believe this is a bug as the purposes of var_dump and var_export are
entirely different:
var_dump - simply dumps a readable form
var_export - exports valid PHP! This code is actually usable within an
application.
var_dump therefore can "manage" the recursive nature of global by simply doing
the following in the output
&array(15) {
["GLOBALS"]=>
*RECURSION*
var_export on the other hand clearly can't take the same approach to recursion
if the generated PHP output is to work as intended by the application designer.
- it can only (and should only) fail.
hope this is useful to someone.
[2010-10-28 20:49:29] hendy at soluvas dot com
This bug is VALID!
The following code works:
var_dump($GLOBALS);
Therefore the dumping algorithm is inconsistent. var_export() should just use
the same algorithm as var_dump().
[2010-06-27 05:55:26] jdickey at seven-sigma dot com
Derick, I'd suggest that that "expected behavior" itself is a design flaw in
the
PHP interpreter. The solutions I can think of right off would be ugly, granted
(special-case check for global-variable accessor to detect whether it's
attempting
to recurse as an effect of debug_backtrace() and, if so, throw an exception
that
can then be caught by d_bt); I find it really hard to believe that such a
heavily-
used software platform with such a large, competent company and community
behind
it can't come up with a better solution.
Marking this bug as 'bogus' merely insults your developer customers and
encourages
them to go find a real language instead.
[2004-11-15 20:19:24] der...@php.net
There is no way to return a correct output in this case, so this is not a bug
but expected behavior.
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=30471
--
Edit this bug report at https://bugs.php.net/bug.php?id=30471&edit=1
