#24346 [Opn->Bgs]: ob_start wrongly optimized out when no callback specified

ID: 24346 Updated by: derick@php.net Reported By: pitrou at free dot fr -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Linux PHP Version: 4.3.2 New Comment: You should use NO parameter if you don't want a handler. PHP 4.3.2 correctly returns FALSE in this case. Previous Comments: ------------------------------------------------------------------------ [2003-06-26 09:33:35] pitrou at free dot fr Description: ------------ Newly with PHP 4.3.2, calls to ob_start with an empty handler (i.e. ob_start("")) seem to be optimized out and ignored. This causes two problems : - ob_start("") can be useful if you prefer to process the contents manually by using ob_get_contents() and then ob_end_clean() - nesting of output buffers is broken, because the ob_end() call corresponding to ob_start("") is still taken (which can totally break the page if your ob_start("") is nested inside an ob_start("ob_gzhandler")...) Reproduce code: --------------- ** This one doesn't work (second statement is eaten out) : <?php ob_start("ob_gzhandler"); ob_start(""); echo "first echo<p>"; ob_end_flush(); echo "second echo<p>"; ob_end_flush(); ?> ** This one works (both statements are printed) : <?php function foo($x) { return $x; } ob_start("ob_gzhandler"); ob_start("foo"); echo "first echo<p>"; ob_end_flush(); echo "second echo<p>"; ob_end_flush(); ?> Expected result: ---------------- Both programs should have the same result (i.e. print both statements on screen). Actual result: -------------- The program which calls ob_start with an empty handler fails to display the second statement. In the other program, we circumvent this bug by using a dummy handler, which causes it to work properly. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=24346&edit=1