Bug #50997 [Asn->Csd]: SOAP Error when trying to submit 2nd Element of a choice
Edit report at https://bugs.php.net/bug.php?id=50997&edit=1 ID: 50997 Updated by: dmi...@php.net Reported by:mrsharp at gmx dot de Summary:SOAP Error when trying to submit 2nd Element of a choice -Status: Assigned +Status: Closed Type: Bug Package:SOAP related Operating System: debian PHP Version:5.2.12 Assigned To:dmitry 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-09-03 08:01:18] dmi...@php.net Automatic comment on behalf of dmi...@tpl2.home Revision: http://git.php.net/?p=php-src.git;a=commit;h=4cca6241e03f0abd442fd867f397b14b3be9d0bd Log: Fixed bug #50997 (SOAP Error when trying to submit 2nd Element of a choice) [2012-09-03 08:01:17] dmi...@php.net Automatic comment on behalf of dmi...@tpl2.home Revision: http://git.php.net/?p=php-src.git;a=commit;h=2659f5e88e9e76594aff0d0c27500514dfef2cb2 Log: Fixed bug #50997 (SOAP Error when trying to submit 2nd Element of a choice) [2012-09-03 08:01:16] dmi...@php.net Automatic comment on behalf of dmi...@tpl2.home Revision: http://git.php.net/?p=php-src.git;a=commit;h=0ab27c35a47901173f22d9e50ca75de0263c45a5 Log: Fixed bug #50997 (SOAP Error when trying to submit 2nd Element of a choice). [2012-09-03 08:01:15] dmi...@php.net Automatic comment on behalf of dmi...@tpl2.home Revision: http://git.php.net/?p=php-src.git;a=commit;h=7e816c0921b4fee488d47b8a060ef820a7c46e38 Log: Fixed bug #50997 (SOAP Error when trying to submit 2nd Element of a choice) [2012-09-03 08:01:14] dmi...@php.net Automatic comment on behalf of dmi...@tpl2.home Revision: http://git.php.net/?p=php-src.git;a=commit;h=485c09a3765b900aea182ddd2dded2286fb0749a Log: Fixed bug #50997 (SOAP Error when trying to submit 2nd Element of a choice). 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=50997 -- Edit this bug report at https://bugs.php.net/bug.php?id=50997&edit=1
Bug #63000 [Opn]: MCAST_JOIN_GROUP on OSX is broken
Edit report at https://bugs.php.net/bug.php?id=63000&edit=1
ID: 63000
Updated by: cataphr...@php.net
Reported by:igor at wiedler dot ch
Summary:MCAST_JOIN_GROUP on OSX is broken
Status: Open
Type: Bug
Package:Sockets related
Operating System: Mac OSX 10.7, 10.8
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
What's the situation in OS X 10.8? I'd prefer not to disable this in versions
where it's working.
Previous Comments:
[2012-09-03 05:42:37] larue...@php.net
reeze, this one is not like that one you reported.
that one is trivial, and in some situation it's not a bug ( empty user name is
allowed in theory).
but this is a bug. (I didn't test with this, just judge by the reporting)
[2012-09-03 02:53:16] reeze dot xia at gmail dot com
I haven't use this option before, if it's an important feature,
if your patch didn't apply the only impact is the warning issued ?
that maybe need to be fixed, but if not...
eg this bug https://bugs.php.net/bug.php?id=62881 I reported.
maybe the bug reported may set to won't fix :(
more conversation see: https://github.com/php/php-src/pull/176
anyway I prefer it get fixed :)
[2012-09-03 02:47:47] reeze dot xia at gmail dot com
Ah, you mention which version the bug exist, both 10.7&10.8 right ?
Is there any way to detect whether is broken or not
disable it seems not a better choice.
[2012-09-02 21:41:13] igor at wiedler dot ch
See also: http://trac.videolan.org/vlc/ticket/6104#comment:19
[2012-09-02 21:38:36] igor at wiedler dot ch
Description:
The multicast support in PHP 5.4 makes use of MCAST_JOIN_GROUP if it is
present.
The problem is that OSX 10.7 added the constant, but did not correctly
implement
the feature. This causes the setsockopt call to fail.
The solution to the problem is to not use MCAST_JOIN_GROUP on OSX.
Test script:
---
'224.0.0.251',
"interface" => 0,
));
var_dump($so);
Expected result:
bool(true)
Actual result:
--
PHP Warning: socket_set_option(): unable to set socket option [22]: Invalid
argument in /Users/igor/code/react-mdns-userland/src/React/Mdns/Client.php on
line 27
PHP Stack trace:
PHP 1. {main}() /Users/igor/code/react-mdns-userland/examples/client.php:0
PHP 2. React\Mdns\Client->query() /Users/igor/code/react-mdns-
userland/examples/client.php:10
PHP 3. socket_set_option() /Users/igor/code/react-mdns-
userland/src/React/Mdns/Client.php:27
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63000&edit=1
[PHP-BUG] Bug #63004 [NEW]: errors json_encode do NOT call error handler
From: juzna dot cz at gmail dot com Operating system: Ubuntu 10.04 PHP version: 5.4.6 Package: JSON related Bug Type: Bug Bug description:errors json_encode do NOT call error handler Description: When there is an error within json_encode (e.g. due to invalid utf8), E_WARNING should be raised. However, that doesn't happen in some cases. It doesn't happen when display_errors is set to On. In latest snapshot of 5.4 it does not happen at all. Test script: --- https://bugs.php.net/bug.php?id=63004&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63004&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63004&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63004&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63004&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63004&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63004&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63004&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63004&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63004&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63004&r=support Expected behavior: https://bugs.php.net/fix.php?id=63004&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63004&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63004&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63004&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63004&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63004&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63004&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63004&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63004&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63004&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63004&r=mysqlcfg
Bug #63004 [Com]: errors json_encode do NOT call error handler
Edit report at https://bugs.php.net/bug.php?id=63004&edit=1 ID: 63004 Comment by: juzna dot cz at gmail dot com Reported by:juzna dot cz at gmail dot com Summary:errors json_encode do NOT call error handler Status: Open Type: Bug Package:JSON related Operating System: Ubuntu 10.04 PHP Version:5.4.6 Block user comment: N Private report: N New Comment: Actually, a similar bug (52397) has been known for more than 2 years. In latest snapshot of PHP 5.4 it just got worse :/ Previous Comments: [2012-09-03 22:14:16] juzna dot cz at gmail dot com Description: When there is an error within json_encode (e.g. due to invalid utf8), E_WARNING should be raised. However, that doesn't happen in some cases. It doesn't happen when display_errors is set to On. In latest snapshot of 5.4 it does not happen at all. Test script: --- https://bugs.php.net/bug.php?id=63004&edit=1
Bug #52397 [Com]: json_encode display_errors dependency
Edit report at https://bugs.php.net/bug.php?id=52397&edit=1
ID: 52397
Comment by: juzna dot cz at gmail dot com
Reported by:david at grudl dot com
Summary:json_encode display_errors dependency
Status: Not a bug
Type: Bug
Package:JSON related
PHP Version:5.3.3RC3
Block user comment: N
Private report: N
New Comment:
This bug has been upgraded in latest snapshot of 5.4 - json_encode doesn't
report
errors at all :/
https://bugs.php.net/bug.php?id=63004
Previous Comments:
[2011-01-12 01:18:14] fake at example dot com
This is a valid bug. The point of this bug is that no warning ever is issued if
display_errors is off. The warnings should still be issued, they just shouldn't
be displayed.
ini_set('display_errors', 1);
json_encode("\xFF");
print_r(error_get_last()); //nothing! wtf?
ini_set('display_errors', 0);
json_encode("\xFF");
print_r(error_get_last()); //now its there!
[2010-08-17 14:29:53] il...@php.net
The return values are the same and so is the operation...
[2010-07-22 01:00:35] david at grudl dot com
Description:
Invalid UTF-8 string throws E_WARNING depending on the configuration directive
display_errors:
ini_set('display_errors', 0);
json_encode("\xFF"); // PHP Warning: json_encode(): Invalid UTF-8 sequence in
argument (in error log)
ini_set('display_errors', 1);
json_encode("\xFF"); // *nothing*
This directive determines whether errors should be printed to the screen as
part of the output or if they should be hidden from the user. It should not be
used to change json_encode behaviour.
The same bug affects htmlentities() and htmlspecialchars()
Test script:
---
ini_set('display_errors', 0);
json_encode("\xFF");
htmlspecialchars("\xFF", ENT_COMPAT, 'utf-8');
htmlentities("\xFF", ENT_COMPAT, 'utf-8');
--
Edit this bug report at https://bugs.php.net/bug.php?id=52397&edit=1
Bug #63004 [Opn->Nab]: errors json_encode do NOT call error handler
Edit report at https://bugs.php.net/bug.php?id=63004&edit=1 ID: 63004 Updated by: ras...@php.net Reported by:juzna dot cz at gmail dot com Summary:errors json_encode do NOT call error handler -Status: Open +Status: Not a bug Type: Bug Package:JSON related Operating System: Ubuntu 10.04 PHP Version:5.4.6 Block user comment: N Private report: N New Comment: json_encode() now checks for valid utf-8. It makes no sense to generate warnings for core functionality of the function. You can check json_last_error() for JSON_ERROR_UTF8 if you want to programmatically catch invalid utf-8. Previous Comments: [2012-09-03 22:15:55] juzna dot cz at gmail dot com Actually, a similar bug (52397) has been known for more than 2 years. In latest snapshot of PHP 5.4 it just got worse :/ [2012-09-03 22:14:16] juzna dot cz at gmail dot com Description: When there is an error within json_encode (e.g. due to invalid utf8), E_WARNING should be raised. However, that doesn't happen in some cases. It doesn't happen when display_errors is set to On. In latest snapshot of 5.4 it does not happen at all. Test script: --- https://bugs.php.net/bug.php?id=63004&edit=1
Bug #63000 [Com]: MCAST_JOIN_GROUP on OSX is broken
Edit report at https://bugs.php.net/bug.php?id=63000&edit=1 ID: 63000 Comment by: igor at wiedler dot ch Reported by:igor at wiedler dot ch Summary:MCAST_JOIN_GROUP on OSX is broken Status: Open Type: Bug Package:Sockets related Operating System: Mac OSX 10.7, 10.8 PHP Version:5.4.6 Block user comment: N Private report: N New Comment: It's still broken on 10.8, also returning EINVAL. Previous Comments: [2012-09-03 20:08:14] cataphr...@php.net What's the situation in OS X 10.8? I'd prefer not to disable this in versions where it's working. [2012-09-03 05:42:37] larue...@php.net reeze, this one is not like that one you reported. that one is trivial, and in some situation it's not a bug ( empty user name is allowed in theory). but this is a bug. (I didn't test with this, just judge by the reporting) [2012-09-03 02:53:16] reeze dot xia at gmail dot com I haven't use this option before, if it's an important feature, if your patch didn't apply the only impact is the warning issued ? that maybe need to be fixed, but if not... eg this bug https://bugs.php.net/bug.php?id=62881 I reported. maybe the bug reported may set to won't fix :( more conversation see: https://github.com/php/php-src/pull/176 anyway I prefer it get fixed :) [2012-09-03 02:47:47] reeze dot xia at gmail dot com Ah, you mention which version the bug exist, both 10.7&10.8 right ? Is there any way to detect whether is broken or not disable it seems not a better choice. [2012-09-02 21:41:13] igor at wiedler dot ch See also: http://trac.videolan.org/vlc/ticket/6104#comment:19 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=63000 -- Edit this bug report at https://bugs.php.net/bug.php?id=63000&edit=1
Bug #63004 [Com]: errors json_encode do NOT call error handler
Edit report at https://bugs.php.net/bug.php?id=63004&edit=1 ID: 63004 Comment by: david at grudl dot com Reported by:juzna dot cz at gmail dot com Summary:errors json_encode do NOT call error handler Status: Not a bug Type: Bug Package:JSON related Operating System: Ubuntu 10.04 PHP Version:5.4.6 Block user comment: N Private report: N New Comment: This is the only one function in whole PHP with this behaviour. So is it a new way of error handling or bug? Previous Comments: [2012-09-03 23:36:20] ras...@php.net json_encode() now checks for valid utf-8. It makes no sense to generate warnings for core functionality of the function. You can check json_last_error() for JSON_ERROR_UTF8 if you want to programmatically catch invalid utf-8. [2012-09-03 22:15:55] juzna dot cz at gmail dot com Actually, a similar bug (52397) has been known for more than 2 years. In latest snapshot of PHP 5.4 it just got worse :/ [2012-09-03 22:14:16] juzna dot cz at gmail dot com Description: When there is an error within json_encode (e.g. due to invalid utf8), E_WARNING should be raised. However, that doesn't happen in some cases. It doesn't happen when display_errors is set to On. In latest snapshot of 5.4 it does not happen at all. Test script: --- https://bugs.php.net/bug.php?id=63004&edit=1
Bug #63004 [Nab]: errors json_encode do NOT call error handler
Edit report at https://bugs.php.net/bug.php?id=63004&edit=1
ID: 63004
Updated by: ras...@php.net
Reported by:juzna dot cz at gmail dot com
Summary:errors json_encode do NOT call error handler
Status: Not a bug
Type: Bug
Package:JSON related
Operating System: Ubuntu 10.04
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
It isn't a new mechanism for PHP. We have had things like mysql_error(),
socket_last_error(), oci_error(), ldap_error(), pg_last_error(),
libxml_get_errors(), preg_last_error(), curl_error() and many money for a very
long time.
The main reason to not surface a warning here is that the only way to avoid it
would be to call iconv('utf-8','utf-8',$str) on all strings to be encoded. This
is a huge hassle to do, it is slow, and this is something we actually do
internally in json_encode() to validate utf-8 anyway, so it would be entirely
redundant. And since in many cases you end up passing user data or at least 3rd-
party data directly to json_encode() you would have to always add this
redundant
check.
Previous Comments:
[2012-09-04 03:17:44] david at grudl dot com
This is the only one function in whole PHP with this behaviour. So is it a new
way of error handling or bug?
[2012-09-03 23:36:20] ras...@php.net
json_encode() now checks for valid utf-8. It makes no sense to generate
warnings
for core functionality of the function. You can check json_last_error() for
JSON_ERROR_UTF8 if you want to programmatically catch invalid utf-8.
[2012-09-03 22:15:55] juzna dot cz at gmail dot com
Actually, a similar bug (52397) has been known for more than 2 years. In latest
snapshot of PHP 5.4 it just got worse :/
[2012-09-03 22:14:16] juzna dot cz at gmail dot com
Description:
When there is an error within json_encode (e.g. due to invalid utf8), E_WARNING
should be raised. However, that doesn't happen in some cases.
It doesn't happen when display_errors is set to On.
In latest snapshot of 5.4 it does not happen at all.
Test script:
---
https://bugs.php.net/bug.php?id=63004&edit=1
Bug #43357 [Com]: phpinfo() returns loaded configuration file (none)
Edit report at https://bugs.php.net/bug.php?id=43357&edit=1 ID: 43357 Comment by: kothai_ramanathan at yahoo dot com Reported by:mail at gbsys dot co dot uk Summary:phpinfo() returns loaded configuration file (none) Status: Closed Type: Bug Package:PHP options/info functions Operating System: WIN XP Pro PHP Version:5.2.5 Block user comment: N Private report: N New Comment: Encountered the same problem. In my case, there were some dlls mentioned in php.ini that were not getting loaded properly. I did a "php -m" at the command prompt in the php folder. Corrected the errors (basically commented the dlls that were not required). PHPIniDir was set using double quotes and forward slashes. Then it worked : phpinfo() showed the loaded configuation file and it recognized my mysqli calls. Previous Comments: [2007-11-21 10:40:36] mail at gbsys dot co dot uk manually copying the php.ini file from where it was installed c:\program files\php\ to c:\windows\, where php seems to be expecting it and rebooting the server corrects the problem. [2007-11-21 10:21:46] j...@php.net Obviously no php.ini file is loaded. Check the directory where it's looked for and that it really IS there and the permissions are correct. [2007-11-21 10:12:16] mail at gbsys dot co dot uk Description: php.ini show extension_dir ="C:\Program Files\PHP\ext" but phpinfo() returns 'loaded configuration file (none)' and extension_dir=c:\php5 so no configured extensions are loaded ie.GD2 -- Edit this bug report at https://bugs.php.net/bug.php?id=43357&edit=1
Bug #63004 [Nab]: errors json_encode do NOT call error handler
Edit report at https://bugs.php.net/bug.php?id=63004&edit=1
ID: 63004
Updated by: ni...@php.net
Reported by:juzna dot cz at gmail dot com
Summary:errors json_encode do NOT call error handler
Status: Not a bug
Type: Bug
Package:JSON related
Operating System: Ubuntu 10.04
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
By the way, in PHP 5.5 the behavior here changes and there is no warning at
all. The error will be available via json_last_error() and a second function
which returns a human readable string instead of an error code.
Previous Comments:
[2012-09-04 03:28:46] ras...@php.net
It isn't a new mechanism for PHP. We have had things like mysql_error(),
socket_last_error(), oci_error(), ldap_error(), pg_last_error(),
libxml_get_errors(), preg_last_error(), curl_error() and many money for a very
long time.
The main reason to not surface a warning here is that the only way to avoid it
would be to call iconv('utf-8','utf-8',$str) on all strings to be encoded. This
is a huge hassle to do, it is slow, and this is something we actually do
internally in json_encode() to validate utf-8 anyway, so it would be entirely
redundant. And since in many cases you end up passing user data or at least 3rd-
party data directly to json_encode() you would have to always add this
redundant
check.
[2012-09-04 03:17:44] david at grudl dot com
This is the only one function in whole PHP with this behaviour. So is it a new
way of error handling or bug?
[2012-09-03 23:36:20] ras...@php.net
json_encode() now checks for valid utf-8. It makes no sense to generate
warnings
for core functionality of the function. You can check json_last_error() for
JSON_ERROR_UTF8 if you want to programmatically catch invalid utf-8.
[2012-09-03 22:15:55] juzna dot cz at gmail dot com
Actually, a similar bug (52397) has been known for more than 2 years. In latest
snapshot of PHP 5.4 it just got worse :/
[2012-09-03 22:14:16] juzna dot cz at gmail dot com
Description:
When there is an error within json_encode (e.g. due to invalid utf8), E_WARNING
should be raised. However, that doesn't happen in some cases.
It doesn't happen when display_errors is set to On.
In latest snapshot of 5.4 it does not happen at all.
Test script:
---
https://bugs.php.net/bug.php?id=63004&edit=1
Bug #48289 [Com]: iconv_mime_encode() quoted-printable scheme is broken
Edit report at https://bugs.php.net/bug.php?id=48289&edit=1
ID: 48289
Comment by: sunfeng891031 at gmail dot com
Reported by:astax dot t at gmail dot com
Summary:iconv_mime_encode() quoted-printable scheme is
broken
Status: Closed
Type: Bug
Package:ICONV related
Operating System: *
PHP Version:5.*, 6
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
thanks!it's useful for me !
i used them in my website:
http://www.dualshine.com
Previous Comments:
[2012-06-14 07:19:31] jinhuakehao at hotmail dot com
this is great help to design new bug to any backdoors, thanks so much, it's
Love
from http://www.favordeal.com
[2010-05-04 13:57:13] ahar...@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/.
Thank you for the report, and for helping us make PHP better.
[2010-05-04 13:57:01] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=298963
Log: Fix for bug #48289 (iconv_mime_encode() quoted-printable scheme is broken).
Thanks to Hiroaki Kawai for the original patch.
[2010-02-08 03:55:49] astax dot t at gmail dot com
I'd like to test the patch described in #50954. Is it included into any PHP
build already? Sorry, I don't feel like compiling PHP from sources.
Here is one more reproduce code:
$str =
base64_decode("1Ojr6ODrICLH4O/g5O3uLdHo4ejw8ero6SIgzsDOICLR7uHo7eHg7eoiIPDg5CDv8OXk8fLg4ujy/A==");
$par = array(
'scheme' => 'Q',
'input-charset' => 'CP1251',
'output-charset' => 'CP1251',
'line-length' => 74,
);
$res = iconv_mime_encode('Subject', $str, $par);
$res = iconv_mime_decode($res, ICONV_MIME_DECODE_CONTINUE_ON_ERROR, 'CP1251');
echo 'Result: Length='.strlen($res)." ".$res."\n";
$expected = "Subject: ".$str;
echo 'Expected: Length='.strlen($expected)." ".$expected."\n";
It says result length is 74 chars and expected is 67.
[2010-02-07 17:38:40] j...@php.net
See also bug #50954 (has a patch too)
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=48289
--
Edit this bug report at https://bugs.php.net/bug.php?id=48289&edit=1
Bug #62991 [Asn]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1
ID: 62991
Updated by: dmi...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
I've added a much simpler patch. Please take a look.
Previous Comments:
[2012-09-02 11:50:39] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.phpt
Revision: 1346586639
URL:
https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.phpt&revision=1346586639
[2012-09-02 11:46:56] larue...@php.net
a new patch has been attached, fixed the memleak issue, but the way is a little
tricky, used the op_array->reserved fields.
so I attached it here instead of ci it, wait for if we can find a better way
[2012-09-02 11:45:06] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346586306
URL:
https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346586306
[2012-09-02 11:24:00] larue...@php.net
okey, but is there a way to find out that whether a generator has been run once?
leaks reporting if the closure didn't run.
[2012-09-02 10:26:03] ni...@php.net
Oh, and also, I think it would be a little bit nicer if this:
+ if (execute_data->op_array->fn_flags & ZEND_ACC_CLOSURE) {
+ destroy_op_array(execute_data->op_array);
+ efree(execute_data->op_array);
+ }
would be written as:
+ if (op_array->fn_flags & ZEND_ACC_CLOSURE) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ }
There already is a local op_array variable for execute_data->op_array, so it's
a bit shorter to use ;)
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
