Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39389
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain gmail.com does not designate 82.132.130.151 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <200807261521.03447.arnaud.lb@gmail.com>
References: <1217070146.3105.83.camel@goldfinger.johannes.nop> <87299D15-3B30-4869-865D-6343B4C5623E@php.net> <200807261521.03447.arnaud.lb@gmail.com>
Content-Type: text/plain; charset=ISO-8859-2; delsp=yes; format=flowed
Message-ID: <95190F6B-D82D-4320-8A53-CDD3E42A1F46@gmail.com>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 27 Jul 2008 21:01:19 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] towards 5.3 alpha1
From: michal.dziemianko@gmail.com (Michal Dziemianko)

Hello,

On 2008-07-26, at 14:21, Arnaud Le Blanc wrote:

> On Saturday 26 July 2008 13:57:45 Lukas Kahwe Smith wrote:
>>
>> On 26.07.2008, at 13:02, Johannes Schl=FCter wrote:
>>
>>> Again a general request to the developer and user community at =20
>>> large:
>>> Please concentrate on finding&fixing bugs instead of functional
>>> changes
>>> (including arginfo and parameter_parsing) and to make sure we =20
>>> have all
>>> changes covered in the wiki [2] so they can be added to release =20
>>> notes
>>> and the documentation.
>>
>>
>> Speaking of which, just going through the open 5.3 bugs that have not
>> been assigned to a developer I see the following ones as looking =20
>> to be
>> important to be dealt with:
>> http://bugs.php.net/bug.php?id=3D45044 (relative paths not resolved
>> correctly)
>> http://bugs.php.net/bug.php?id=3D43695 (Asynchronous socket =
connection
>> timing issue)
>> http://bugs.php.net/bug.php?id=3D45384 (parse_ini_file will result in
>> parse error with no trailing newline)
>> http://bugs.php.net/bug.php?id=3D45392 (ob_start()/ob_end_clean() and
>> memory_limit)

I have just taken a look at this bug, and the problems seems to be in =20=

php_request_shutdown function from main/main.c. It just executes =20
buffers flush no matter what outcome of the script was (I mean error/=20
success) (somewhere around line 1495):

zend_try {
	=
php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1) =20
TSRMLS_CC);
} zend_end_try();

It can be avoided by adding if-stmt checking if there was an error:

if (!PG(last_error_message) || !(PG(last_error_type) & E_ERROR)) {
	zend_try {
		=
php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1) =20
TSRMLS_CC);
	} zend_end_try();
}

I am not sure if it is the right solution, or if it does not =20
introduce any other problems I am not aware of (I have done "make =20
test" and haven;t noticed anything strange.)

Cheers
Michal

>> http://bugs.php.net/bug.php?id=3D44842 (parse_ini_file keys that =
start/
>> end with underscore)
>> http://bugs.php.net/bug.php?id=3D45288 (set_include_path() =20
>> functionality
>> broken)
>> http://bugs.php.net/bug.php?id=3D45608 (closures don't work in static
>> methods)
>>
>> The rest are either assigned or PDO bugs (again, we really really
>> really need someone that looks after PDO).
>>
>> Of course there are also still tons of open 5.2 bugs [1] :(
>>
>> regards,
>> Lukas Kahwe Smith
>> smith@pooteeweet.org
>>
>> [1]
> http://bugs.php.net/search.php?=20
> cmd=3Ddisplay&status=3DOpen&search_for=3D&php_os=3D&boolean=3D1&author_e=
mail=3D&bu=20
> g_age=3D0&by=3D&order_by=3Did&direction=3DASC&phpver=3D5.2&limit=3D30&as=
sign=3D&begi=20
> n=3D0
>> --=20
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
> Hi,
>
> For "closures don't work in static methods" (45608), this is =20
> because a closure
> declared in a static method will always be called statically.
>
> The example given in the report works if the closure is explicitly =20
> declared as
> static, but as shown by the bug report it may be better to =20
> implicitly inherit
> the ACC_STATIC flag of the declaring method. It seems that =20
> Christian planed
> to add this to his patch but it has never be included.
>
> This could be as simple as this:
> http://arnaud.lb.s3.amazonaws.com/closure_static.patch
>
> For "relative paths not resolved correctly" (45044) I added a =20
> comment on the
> report about the cause of the bug, but I don't know what is the =20
> better way to
> fix that.
>
> Regards,
>
> Arnaud
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>