Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:23969 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85404 invoked by uid 1010); 6 Jun 2006 11:30:07 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 85388 invoked from network); 6 Jun 2006 11:30:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jun 2006 11:30:07 -0000 X-Host-Fingerprint: 80.123.98.46 unknown Received: from ([80.123.98.46:29018] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 62/60-00946-E3765844 for ; Tue, 06 Jun 2006 07:30:07 -0400 Message-ID: <62.60.00946.E3765844@pb1.pair.com> To: internals@lists.php.net Date: Tue, 06 Jun 2006 13:30:02 +0200 User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 80.123.98.46 Subject: func/006.phpt fails with new output control code From: mike@php.net (Michael Wallner) Hi, Tony noticed that func/006.phpt fails with the new output control code. The test assumes that the buffer returned by ob_get_contents() is unicode when unicode_semantics=1. I think the test and previous behaviour are wrong. Though everything reaching the output layer should be in output_encoding, we cannot know if the output handler buffer we are going to return came from another output handler and what transformations it did to it. Thus, ob_get_contents() always returns a binary string. See also tests/output/ob_016.phpt Another undiscussed issue is that output handlers receive binary only strings, too, of course, but in a controlled environment the developer should probably always know what she's going to get passed in the output handler so she can convert it to unicode if needed. Opinions, thoughts, flames? :) Regards, -- Michael