#49765 [Opn]: Closure: Unreachable static declaration breaks lexical reference
ID: 49765 Updated by: rob...@php.net Reported By: rob...@php.net Status: Open Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3SVN-2009-10-04 (snap) New Comment: >From an implementation perspective, I can see why using the static_variables container for lexical vars makes sense. But I think the behaviour above might be too prone to confusion. Perhaps there could be a warning when name clashes are detected, or at least something in the doc? Previous Comments: [2009-10-04 13:00:11] rob...@php.net Description: Hi, Closures' lexical variable descriptors are stored in the same container as function-scope statics: zend_function.op_array.static_variables. This can cause unexpected behaviour when the same name is used for a lexical variable and a function-scope static. For example, the testcase below shows how an apparently unreachable function-scope static declaration impacts an assignment to a lexical reference. This is because static declarations are identified at compile time (regardless of the execution path within the function), and they end up taking precedence over lexical vars. Reproduce code: --- http://bugs.php.net/?id=49765&edit=1
#46903 [Asn->Csd]: ob_start(): Special $chunk_size value of 1 is not honoured in HEAD
ID: 46903
Updated by: rob...@php.net
Reported By: robin_fernandes at uk dot ibm dot com
-Status: Assigned
+Status: Closed
Bug Type:Output Control
PHP Version: 6CVS-2008-12-18 (snap)
Assigned To: robinf
New Comment:
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.
Previous Comments:
[2008-12-23 19:10:50] fel...@php.net
Commit it :)
[2008-12-18 14:40:09] robin_fernandes at uk dot ibm dot com
Description:
The doc for ob_start() states:
"If the optional parameter chunk_size is passed, the buffer will be
flushed after any output call which causes the buffer's length to equal
or exceed chunk_size . Default value 0 means that the function is called
only in the end, other special value 1 sets chunk_size to 4096."
In HEAD, setting $chunk_size=1 actually does set the buffer threshold
size to 1 byte, rather than 4096 bytes as on 5_* and as documented.
Here's a simple patch for HEAD to restore the documented behaviour:
Index: output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.214
diff -u -w -p -r1.214 output.c
--- output.c18 Aug 2008 07:45:59 - 1.214
+++ output.c18 Dec 2008 14:23:10 -
@@ -1342,6 +1342,8 @@ PHP_FUNCTION(ob_start)
}
if (chunk_size < 0) {
chunk_size = 0;
+ } else if (chunk_size == 1) {
+ chunk_size = 4096;
}
if (SUCCESS != php_output_start_user(output_handler, chunk_size,
flags TSRMLS_CC)) {
Reproduce code:
---
1, these two chars should
// come out as part of a single flush:
echo "1";
echo "2";
?>
Expected result:
[1] int(4096)
12
Actual result:
--
[1] int(1)
[2] 1
[3] 2
[4]
--
Edit this bug report at http://bugs.php.net/?id=46903&edit=1
#46900 [Asn->Csd]: Unexpected behaviour in HEAD when output buffer callback returns null
ID: 46900
Updated by: rob...@php.net
Reported By: robin_fernandes at uk dot ibm dot com
-Status: Assigned
+Status: Closed
Bug Type: Output Control
Operating System: *
PHP Version: 6CVS-2008-12-18 (snap)
Assigned To: robinf
New Comment:
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.
I updated testcases ob_014.phpt and ob_015.phpt which relied the
original behaviour.
Previous Comments:
[2008-12-24 19:50:14] fel...@php.net
Commit it too.
Thanks.
[2008-12-18 14:15:50] robin_fernandes at uk dot ibm dot com
Description:
In HEAD, the original input is sent to the output when the output
buffer callback returns NULL. The docs for ob_start() only state this
should happen when it returns FALSE - not NULL:
"If output_callback returns FALSE original input is sent to the
browser."
On PHP 5_2 and 5_3, the empty string is sent to the output when the
output buffer callback returns NULL.
If the 5_2 & 5_3 behaviour is correct, here is a patch for HEAD :
Index: output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.214
diff -u -w -p -r1.214 output.c
--- output.c18 Aug 2008 07:45:59 - 1.214
+++ output.c18 Dec 2008 14:08:53 -
@@ -983,7 +983,7 @@ static inline php_output_handler_status_
ZVAL_LONG(ob_mode, (long) context->op);
zend_fcall_info_argn(&handler->func.user->fci
TSRMLS_CC, 2,
&ob_data, &ob_mode);
-#define PHP_OUTPUT_USER_SUCCESS(retval) (retval && (Z_TYPE_P(retval)
!= IS_NULL) && (Z_TYPE_P(retval) != IS_BOOL || Z_BVAL_P(retval)))
+#define PHP_OUTPUT_USER_SUCCESS(retval) (retval && !(Z_TYPE_P(retval)
== IS_BOOL && Z_BVAL_P(retval)==0))
if (SUCCESS ==
zend_fcall_info_call(&handler->func.user->fci,
&handler->func.user->fcc, &retval, NULL TSRMLS_CC) &&
PHP_OUTPUT_USER_SUCCESS(retval)) {
/* user handler may have returned TRUE */
status = PHP_OUTPUT_HANDLER_NO_DATA;
If HEAD's current behaviour is as intended, the docs should be updated
to describe the new behaviour in PHP6.
Reproduce code:
---
Expected result:
done
Actual result:
--
You shouldn't see this.
done
--
Edit this bug report at http://bugs.php.net/?id=46900&edit=1
