Edit report at https://bugs.php.net/bug.php?id=60175&edit=1
ID: 60175
Updated by: m...@php.net
Reported by: artificialmagic at hotmail dot com
Summary: ob_implicit_flush is brain-damaged or something I
dunno
-Status: Open
+Status: Bogus
Type: Bug
Package: Output Control
PHP Version: 5.3.8
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
"output call" means system output call.
chunk_size==1 has a special meaning for ob_start, because you can specify
output_buffer=on in php.ini.
STDOUT and php://stdout are just stream wrappers.
Your language is funny though.
Previous Comments:
------------------------------------------------------------------------
[2011-10-30 17:21:26] artificialmagic at hotmail dot com
By the way I already tried using a stream filter instead of output buffering,
adding it with:
stream_filter_append(STDOUT, 'BlahFilter');
and:
stream_filter_append(fopen('php://output', 'wb'), 'BlahFilter');
But it had absolutely no effect. I'd like to say I'm surprised, or even vaguely
confused, but sane behavior from PHP is rarer than a ST:TOS redshirt that
survives their first away mission.
------------------------------------------------------------------------
[2011-10-30 15:32:27] artificialmagic at hotmail dot com
Description:
------------
I'm trying to use output buffering in CLI to log output as it's echoed. But
ob_implicit_flush is a bunch of feral cock. Look at this bullpoop:
Test script:
---------------
ob_start(function ($s) {
return "[" . strlen($s) . "]";
});
ob_implicit_flush(true);
for (;;) echo '.';
Expected result:
----------------
[1][1][1][1][1][1][1][1]... ad infinitum
Actual result:
--------------
Nothing is ever displayed.
Memory usage goes up and up until the script crashes. PHP would be quite happy
apparently to consume additional universes if it could get more memory out of
it to fill with "."'s.
The documentation says "Implicit flushing will result in a flush operation
after every output call". Well maybe it does do that, I don't know, but
whatever it's doing it doesn't generate the result implied by the
documentation. It's a God-damn lie in spirit. I feel betrayed.
Try to specify 1 as the buffer size to ob_start as a workaround. Just TRY IT,
and watch the sheer audacity of the thing as it calmly prints out
[4096][4096][4096][4096][4096][4096].... Because apparently some herp-derp
let's-just-add-random-quirks-for-laughs moron at PHP bollocksing years ago
decided 1 = 4 kB. That's a nice idea isn't it. That's real fucking neato.
The best I can get apparently is to specify a buffer size of 2 to ob_start,
which will cause [2][2][2][2][2][2][2][2][2][2]....
But that's no fucking good because individual characters won't echo until
another one happens to come along. THIS IS A PROGRAMMING LANGUAGE NOT THE BUS
STOP.
If you can't make ob_implicit_flush do what it blatantly claims it will do
could you at least make -1 to ob_start a synonym for a real 1 so this can be
made to work. Thanks very much. Meanwhile I'll just go and drown myself in a
see of hideous synonym functions ("echo2($boop);", "var_dump2($blah);"). Don't
worry about me, I completely enjoy that.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=60175&edit=1
